- From: Tim Berners-Lee <timbl@w3.org>
- Date: Wed, 22 Jan 2003 08:13:36 -0500
- To: "Tim Berners-Lee" <timbl@w3.org>
- Cc: <www-xml-linking-comments@w3.org>
IMHO ----- Original Message ----- From: "MURATA Makoto (FAMILY Given)" <EB2M-MRT@asahi-net.or.jp> To: <www-xml-xinclude-comments@w3.org> Cc: <www-xml-linking-comments@w3.org>; <www-tag@w3.org> Sent: Friday, December 27, 2002 2:48 AM Subject: Architectural problems of the XInclude CR > > I think that the XInclude CR has significant problems and that > it should not become a recommendation in its current form. > > 1) XInclude ignores the media type (and probably the charset > parameter) associated with resources > > When parse = "xml" is specified, XInclude always assumes that the > media type is text/xml and the fragment id is an XPointer. When parse > = text" is specified, XInclude always uses text/plain in interpreting > fragment identifiers. It is unclear whether or not XInclude respects > the charset parameter of the original media type. I would thus argue > that XInclude conflicts media type RFCs and architectural > principles of W3C (2.4. Fragment identifiers of "Architecture of the > World Wide Web", Draft 15 November 2002). There is a confuion in the messages about this topic between two functions: a) Determining what the actual MIME type of a resource is, and b) Determining functions applied to a document in the XInclude process. As regards (a), you are right that the web architecture is broken by an attempt to say, "Never mind what the webs erver says, its XML". It moves to world in which no one can make a link without specifying two things (the mime type and URI) instead of one (the URI). The worrying phrase in the XIncldue spec text is "coerced to XML" - which is not as far I can see explained. The fact is that XIncldue operates at he syntactic level, and (in parse-xml mode) can only incldue XML syntax. So if the document is actually served as for example SVG, that should matter in my opinion - the XInclude just operates on the syntax. Clearly a warning about content negotiation should be used - because XInclude operates at the syntactic, not functional, level, there is no way that a content negoatiated resource should be used. They are if you like features you just don't use together. MURATA Makoto (FAMILY Given) <EB2M-MRT@asahi-net.or.jp>; www-xml-xinclude-comments@w3.org www-xml-xinclude-comments@w3.org cc MURATA Makoto (FAMILY Given) <EB2M-MRT@asahi-net.or.jp>; www-xml-xinclude-comments@w3.org <www-xml-xinclude-comments@w3.org> If one wanted a way of giving a hint to an application as to the mime type of a file, then that should be tackled as a separate problem - for use anywhere. I agree that "When the resource is coerced to text/xml, the fragment part of the URI reference is interpreted as an XPointer, regardless of the media type of the resource" seems a direct breaking of the architecture, and also a possible huge bug. This seems unnecessary when operatingin mode (i) below and the sort of thing which would hide errors. As regards (b), there is a reasonable distinction between different functions, but the spec should be more clear. It isn't just the way something is parsed - it is more like the function which is being performed is different. PCDATA is being included as a result of a transformation on a plain text input. (i) Incorpoarting the infoset of the included document into the infoset of the main document. (ii) Taking a plain text document, and converting it into PCData for insertion into the infoset. This is reasonable so long as one figures out what to do with line breaks (@@?) One could have a reasonable expectation that the intenet of the plain text document would be carried into the XML document. For example, you could include a plain text warning into a structured document. (iii) Taking a plain text document, and treating it as XML, and incorporating the infoset so obtainted into the infoset. This is adding an extra (level-breaking) parse. This takes something published in raw source form and interpreting it as XML. This may be a useful fucntion , but it is a level beeaker and should be clearly distinguished as such. (iv) Taking an XML document, breaking the XML infoset level byaccessing its raw source, converting that raw source into PCdata and inserting it into the docuemnt. This is a level-breaker used (like many level-breakers) for debugging, making examples etc, and so long as it is clealy labelled it seems to be OK. The top two are the straightfoward way of using XInclude. I hope they will be much the most frequently used. The other two are kludges,and I would suggest they not be the default. > 2) XInclude uses text/xml rather than application/xml > > Most XMLers prefer application/xml to text/xml, since XML documents > are not readable by casual users (see RFC 3023). Some people even > propose to drop text/xml. I believe that application/xml should be > used, even if my first comment is turned down. > > 3) XPointer is not a set of W3C recommendations yet > > When the final decision on the set of XPointer specifications is made, > XInclude should be modified. > > 4) XInclude blesses XPointer as fragment identifiers of text/xml, > while RFC 3023 (XML media types) does not. > > RFC 3023 does not normatively reference to XPointer. It simply > mentions XPointer as a possibility. However, XInclude uses XPointer as > fragment identifiers of text/xml. Before XInclude becomes a W3C > recommendation, a new RFC for XML media types should be developed and > XPointer should be registered as fragment identifiers of XML media types. > > -- > MURATA Makoto (FAMILY Given) <EB2M-MRT@asahi-net.or.jp> >
Received on Wednesday, 22 January 2003 12:15:33 UTC