[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Inconsistency between IETF and W3C: XML fragments and media types
Chris Lilley wrote:
> Dan Connolly wrote:
> > I wonder why it's mandatory.
> Because typically, CSS processors cannot deal with XSL stylesheets and
> XSL processors cannot deal with CSS stylesheets, and avioding
> downloading the thing if it is not a type you can process is highly
Yes, well... "typically" and "highly desirable" add up to SHOULD
or even STRONGLY RECOMMENDED; but not MUST.
MUST complete precludes content negotiation, where the client advertises
its capabilities when fetching the stylesheet, and the server
chooses the best representation.
> > Anyway... the type="text/xml" in the XSLT spec example is saying:
> > "the stylesheet I'm pointing to is written in XML;
> It would be more useful to say it is written in XS:L
yes, as discussed below...
> (is thatwhat you
no. I meant what I wrote.
> > This is a case where it might be useful to have a specific MIME
> > type for XSL(T),
> There was one, last I looked.
I suggest you look again; I'm pretty certain there isn't one.
> > so that you could say:
> > "the stylesheet I'm pointing to is written in XSL; if you don't
> > grok XSL, don't bother fetching it."
> > " draft-murata-00: Application/xml-dtd, a naming convention (*/*-xml),
> > and examples (application/mathml-xml, application/xsl-xml,
> > application/rdf-xml, and image/svg-xml) are added."
> > I don't care for that idea.
> Because ....
Sorry... because it encourages folks to extract structure from
the subtype name, which is specified in the MIME spec as an atomic unit.
It smells like a kludge.
While it suggests that
if a MIME type consists of XML documents, then it should be named
I wonder if it guarantees that
if a MIME type matches */*-xml then it consists of XML documents
But reviewing it more closely, the kludge seems thorough:
The registrar for the IETF tree will enforce this rule
for all XML-based media types created in the IETF tree.
Hmm... maybe not; this seems problematic:
This convention will
allow applications that can process XML generically to detect that
the MIME entity is supposed to be an XML document, verify this
assumption by invoking some XML processor, and then process the XML
The text/xml MIME type isn't limited to well-formed documents, but
to XML entities (c.f. 2nd para under 3. XML Media Types of
http://www.ietf.org/internet-drafts/draft-murata-xml-01.txt); so the
Four score and seven years ago
is a valid text/xml body, but an XML processor will burp cuz there's
no root element.
> Have you been following the IETF/W3C/IMC joint mailing list about MIME
> types for XML?
I read the archive now and then. I see lots of questions and
few well-tested answers.
The whole problem of MIME types for XML with namespaces looks, to me, as
hard as the whole software installation dependency problem; what's
to happen when I click on foo.xml on a wintel box? Given some list of
linux RPM packages, how many do I have to install (and which ones)
before my machine groks some new XML namespace?
It seems worthwhile to brainstorm about designes and/or conventions and
them out; but it seems premature, to me, to standardize the ideas I've
> That is where this -xml stuff originated from.
Yes... but I hope folks aren't taking my silence as agreement to
that is proposed in this forum.
> I *do* like image/svg-xml, actually. It certainly better than either
> image/svg or application/xml in terms of saying what the SVG file
I don't have any particular objection to image/svg-xml; it works
as well as any other arbitrarily named subtype of image or
application, as far as I'm concerned.
Dan Connolly, W3C