[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Inconsistency between IETF and W3C: XML fragments and media types
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.
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
> 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
> 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.
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
> > 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
> 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.