Larry Masinter wrote:
My guess is that the registration would push back and suggest
registering them as "application" and possibly as faceted
"application/vnd.ms-vbscript", "application/vnd.tcl".
Who is the "vendor" of TCL?
That leads to another issue: MIME type are not only used to get the
interpretation started, but also to negotiate capabilities between a
client and a server, e.g., in HTTP. In that context, sending a
document with embedded XSL to a client that has indicated not being
able to handle XSL is not very smart.
True, although if it couldn't, the server would need to be smart to
strip out the XSL (or indeed, to pre-process it on the server). This is
where a reference rather than explicit content can be helpful - the
script is requested in a separate request, and can be content
negotiated.
MIME types aren't used effectively for HTTP negotiation; the use
of "Accept" headers has proven unwieldy.
Yes, the early browsers didn't "get it" and sent the same string
regardless of the request; the adoption of plug-in architectures did not
produce any change in the Accept header, and more imporantly, the bulk
of content authors are no longer in control of the servers they use, and
so cannot add new MIME types or configuration options such as qs
factors. Which, of course, not only calls into question coneg but also
the use of MIME types itself.
However, conneg based on Accept can still be useful today - it is more
robust and scalable than recognising user agent identification strings,
for example - and is used on the W3C site to send a PNG (if the client
can accept it) or a GIF (if not).
We're still looking for
some other kind of capability/profile mechanism that would be suitable.
The CONNEG work and the continuing CCPP work in W3C will hopefully
yield a workable mechanism.
Yes. One thing that would help would be a standard resource description
which could be uploaded (users can still upload files) along with the
actual content, and would affect only the listed resources. That might
allow more flexible content negotiation without server reconfiguration,
cgi scripts, or servlets.
In other words, that document with its embedded XSL needs not just a
MIME type for its first byte, but also a description (a "profile") of
the other capabilities a client needs. That would be something like a
CC/PP( http://www.w3.org/Mobile/CCPP/ ) profile, I assume, and inside
that there *would* be an entry that says "application/xsl" (or whatever
the MIME type will be).
It isn't necessary to have a MIME type to talk about a capability.
That is, you could have a feature which is "able to interpret XSL style"
without registering "application/xsl".
True. There are other alternatives to MIME types.
The recognition that MIME labelling is insufficient for fine-grained
description of recipient capabilities or document profiles was the
foundation of the CONNEG work; it seems likely that CCPP can use the
CONNEG registry and a superset of the semantics of CONNEG feature
sets, although likely with an XML (RDF?) based syntax for feature sets.
See http://www.imc.org/ietf-medfree
Thanks for the reference. Interesting work.
--
Chris