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

Re: Inconsistency between IETF and W3C: XML fragments and media types

1999-11-24 23:33:25


Dan Connolly wrote:

Chris Lilley wrote:

Dan Connolly wrote:
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.

Yes.

Its the sort of kludge that hapens when some folks would like a
multi-tier rather than two-tier name, or would like a new top level
type, or to use parameters; and when other folks have been dead set
against suchthings for years, and think that the existing two-tier
system is already too much.

A compromise, in other words.

Yes, it would formalise a particular meaning for the string "-xml" when
appearing at the end of a subtype.


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

I suspec that in this case,registration would not be allowed.

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.

Why is that problematic? Its says that applications which have xml
parsers can request any MIME type tha uses XML, and process the result
any way it wants to.

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.

Thi si s agood point, which had escaped my notice before. Certainly, it
should be a requirement that text/xml (or the preferred application/xml,
which avoids silly crufty rules about charsets) is always a well formed
XML instance, and things thatare now well formed XML use a different
type.

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.

;-)

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.

OK.

--
Chris

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