W3C home > Mailing lists > Public > www-tag@w3.org > July 2003

More thoughts on 'Client handling of MIME headers'

From: Chris Lilley <chris@w3.org>
Date: Mon, 14 Jul 2003 20:34:57 +0200
Message-ID: <1247165733.20030714203457@w3.org>
To: WWW-Tag <www-tag@w3.org>

Hello WWW-Tag,

>> Another benefit of separating metadata that guides interpretation
>> from data is improved efficiency. For instance, when a server sends
>> XML data and labels the data correctly through MIME headers, a
>> client can dispatch processing after rapid inspection of the
>> metadata (typically short strings). It is much more expensive if
>> the client has to start up an XML parser to guess the content type.

Its not clear that this assertion is true.

So I send some xml data labelled as application/xml and it contains a
bunch of xml namespaces (but I am not going to tell you what they are
or what the rootmost one is, because you need to parse the xml to get
that information). Similarly, peeking in the xml and noticing that
there is a PI to link to a stylesheet is also not allowed here. So
what can really be done?

So, starting an xml parser (or attaching to an existing one) should
not be needed for 'guessing the content type', true, but may well be
needed to decide on appropriate processing.

I certainly agree that startiong a parser to see if it is xml would be
a bad thing.

The trouble in the text above is that it goes straight from
'determining content type' to ' dispatch processing' while assuming
the latter is an atomic, single step process.

So I would agree that correct labelling allows the first step to be
dispatching to be done automatically; the current text seems to
suggest that there can only be one step, and there I disagree. Given a
firm identification of content as application/xml, parsing the content
is a likely and reasonable second step and the finding should take
care not to inadvertently suggest otherwise.

 Chris                          mailto:chris@w3.org
Received on Monday, 14 July 2003 15:21:46 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:55:59 UTC