ietf-xml-mime
[Top] [All Lists]

RE: Media types for XSL stylesheets

1999-10-12 10:18:03
On the other hand, if you have a format that allows a wide, maybe even
open-ended range of things to be embedded in it, such as a multipart
MIME message, or the SCRIPT element of HTML, then you need a more
flexible way to label the embedding. MIME types seem to do that very
well, so both these formats have adopted them as the labeling
mechanism.

Actually, there's an issue with HTML use of MIME to label SCRIPT
elements: no one has registered any MIME types for embedded script
languages. Although the HTML 4.0 document mentions "text/javascript",
"text/vbscript", "text/tcl" in examples, they're not registered.
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".


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.

MIME types aren't used effectively for HTTP negotiation; the use
of "Accept" headers has proven unwieldy. 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.

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".

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




Bert
-- 
  Bert Bos                                ( W 3 C ) http://www.w3.org/
  http://www.w3.org/people/bos/                              W3C/INRIA
  bert(_at_)w3(_dot_)org                             2004 Rt des Lucioles / 
BP 93
  +33 (0)4 92 38 76 92            06902 Sophia Antipolis Cedex, France



<Prev in Thread] Current Thread [Next in Thread>