On 12/15/06, Bob Wyman <[EMAIL PROTECTED]> wrote:
On 12/15/06, Hugh Winkler <[EMAIL PROTECTED]> wrote:
> It's telling that James felt it natural to choose the name "type" for
> the parameter. Because it really is naming a new type of document.
What would be better than "type?" Might "root" work better?
No, my point was that "type" is right on the money; it correctly
describes what you're doing... defining a new mime type, but
overloading the parameter mechanism to do so.
It seems to me that "application/atom+xm;type=entry" describes "an Atom document whose root element is `<entry/>'." The type
of the document is "atom" but it is a "kind" or "type" of atom document that has an <entry/> element as it's root.
Unfortunately, "type" is being used to mean two completely different things in this context.
Would you be happier if the proposal was for the following?
application/atom+xml;root=entry
application/atom+xml;root=feed
No.
One argument for using "root" is that it might be a usage that would be useful with other mediatypes which have more than one possible
root element. Also, using "root" as the parameter name would ensure that folk don't get confused into thinking that there is any kind
of subtyping going on here -- specifying ";type=root" is simply providing meta-data which describes a constrained use of the general
atom type -- it is no different from doing something like saying: "I won't except any feeds that don't have <icon/> elements."
or, "This feed contains no more than 256 entry elements." If one is being exceptionally formal or overly pedantic, I can see how you
might argue that a feed constrained to fewer than 257 entries is somehow a sub-type of sub-class of the more general atom type. But, since every
distinct instance of the atom type can be described in similar manners, it would mean that every atom instance is a "subtype." In some
contexts, this observation might be useful. I!
don't think, however, that such precision is useful in the realm for which we
normally are designing Atom...
Straw man: I didn't even remotely imply that all uses of mime
parameters is the same as subclassing. In this case, yes, as betrayed
by the natural choice of language.
When James's proposal came up, I happened to have just constructed
some server code (not Atom-specific) to dispatch PUT and POST based on
the mime type of the request entity. You just do a simple string match
on the bit in front of the semicolon, and dispatch based on that. It's
very easy to parameterize that mechanism: any plugin can declare it
handles "application/atom+xml". It's not such a big deal if the
handler for "application/atom+xml" has to further dispatch based on
the parameters, but you can see it's duplicative. The reason for the
duplication is a little imperfection in the modelling. If the WG
decides other considerations outweigh this one, programmers will
handle it. No biggie.
But lots of mime type dispatch code lives in browsers, and in servers,
and most of the mime.types-ish files you see never have a semicolon in
them. (James is correct that you can put the parameter in mime.types
for Apache, but of course that is a case of dispatching based on file
extension, not on mime type).
Hugh
