Hi Jon,
Some comments on your paper on implementing the Warwick Framework (WF)
using MIME.
First - a terminology nit. You refer to "three requirements". Carl's
paper actually calls those "manifestations". In addition to the
manifestations, his paper has 7 requirements. You may want to address
those requirements as well as show how MIME can deal with the
manifestations.
Second, Carl's paper defines "containers" and "packages" as
being the core concepts of the WF. I would have liked to see
a very explicit treatment of how containers are represented in
MIME, and how packages are represented. For containers this might
be a couple of sentences like:
The Warwick Framework is based on the concepts of containers
and packages. For MIME implementations of the WF, continers
shall be encoded using the multipart/mixed Content-type. (or
multipart/related? I would like to see arguments on the merits of
the two approaches).
For packages the situation is almost as straightforward.
Carl's paper defines three types of packages: primitive, indirect,
and container. Container packages are treated the same as above -
use multipart/mixed (or related). For indirect packages we probably
want to use MIME's message/external-body content type. A reference
to an external package might look like:
Content-type: message/external-body; access-type=URI;
name="http://www.foo.bar.com/path/huh.sgml"
Content-type: application/usmarc
Content-ID: <[log in to unmask]>
Content-Transfer-Encoding: binary
(Note that the URI access-type is not registered. This is a reasonable
task to be done).
The third type of package is "primitive", this is the case where
the data is actually there in the package. MIME's normal Content-type
mechanism is sufficient for identifying the information here.
I think the WF/MIME document should talk about those sorts of things,
but use an appropriately stuffy tone of voice, after all it is
to be a standard, right?
I disagree with your suggestion of x-metadata as a major type for
several reasons. First, I think it contradicts the spirit of
packages as first-class citizens of the net. Instead, we are always
identifying packages as subservient to something else. Second, the major
MIME types make particular distinctions about the type of software
that is needed to handle the data. text/* means that, if worst comes
to worst, you can just hand it off to a human and they stand a chance
of reading it. application/* means that humans have no real chance of
reading it. image/*, video/*, audio/* all give info on the type of
data being sent. x-metadata/* does not provide the same sort of info.
Can a human read it or not? text/sgml and application/USMARC give us
clues to answer that question, x-metadata does not. Finally, I object to
it on standardization grounds. Given the allergic reaction of most of
the IESG to the "m-word", and given the MIME standard's expressed
intention of SEVERELY limiting the registration of new major types,
there is not a snowball's chance of ever seeing a metadata/* MIME type.
(Nor do I think there should be). The x- prefix is equivalent to
"here is a little test hack between friends, and we will never try
to go for standardization on this". However, I think that we want to
try to standardize the WF stuff, or at least not rule it out.
Your suggestion of new sub-types, such as x-dcessgml, is
more agreeable, but I would urge you to be careful about using the
x- prefix. Some of the content types I think we want to use,
like application/usmarc, really do not need the x-, and having
it only slows things down and gives us a backward compatibility
problem. Also, the Dublin Core Element Set in SGML type (dcessgml)
is probably more suited to the existing text/sgml type.
BTW - I like the paper more than this note would imply. I think that
MIME can be used to implement the WF in a reasonable fashion. The hard
part is going to be getting the same capabilities into all the
versions (CORBA, SGML, and MIME).
Best regards,
--
Ron Daniel Jr. email: [log in to unmask]
Advanced Computing Lab voice: (505) 665-0597
MS B-287 TA-3 Bldg. 2011 fax: (505) 665-4939
Los Alamos National Lab http://www.acl.lanl.gov/~rdaniel/
Los Alamos, NM, 87545 tautology: "Conformity is very popular"
|
