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

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
dynamically
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
> meant?)

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."
> 
> Exactly.
> 
> > "   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
*/*-xml
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
	document accordingly.

The text/xml MIME type isn't limited to well-formed documents, but
rather
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
following:

	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
supposed
to happen when I click on foo.xml on a wintel box? Given some list of
installed
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
try
them out; but it seems premature, to me, to standardize the ideas I've
seen.

> That is where this -xml stuff originated from.

Yes... but I hope folks aren't taking my silence as agreement to
everything
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
> contains.

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
http://www.w3.org/People/Connolly/

Received on Thursday, 25 November 1999 01:01:27 UTC