- From: <noah_mendelsohn@us.ibm.com>
- Date: Fri, 16 Jan 2009 16:04:57 -0500
- To: Mark Baker <mark@coactus.com>
- Cc: www-tag@w3.org
Mark Baker wrote: > My concern is with the mention of the application/xml media type > there, which I feel inappropriate because RFC 3023 doesn't license, > for example, that an XHTML document delivered as application/xml is > intended to evoke XHTML semantics. Mark, thank you as always for your comments. We have discussed this extensively at several face to face meetings, and I believe we came out comfortable that RFC 3023 [1] does support inferrence of XHTML semantics, albeit indirectly. For example, it says: "An XML document labeled as text/xml or application/xml might contain namespace declarations, stylesheet-linking processing instructions (PIs), schema information, or other declarations that might be used to suggest how the document is to be processed. For example, a document might have the XHTML namespace and a reference to a CSS stylesheet. Such a document might be handled by applications that would use this information to dispatch the document for appropriate processing." I think we convinced ourselves that, particularly in the case where a namespace document is available at the namespace URI, 3023 does allow one to infer that the semantics can be inferred from the qualified names (or more specifically, from the corresponding expanded names) of the elements used in the document. This was quite crucial to resolving a difficult discussion, so I have some reluctance to reopen it this late in the publication cycle unless there's pretty clear evidence that we've misunderstood 3023. It certainly seems desirable to me that user agents receiving a document of media-type application/xml be allowed, in the cases where they recognize the qualified names of the root and other elements, to apply the semantics of those names to the document. If there is any ambiguity, I'm tempted to suggest that it be resolved by clarifying 3023, rather than by changing the SDW finding. > Also, in section 6.1, reference is made to RFC 2717 (as an example) > which has been obsoleted by RFC 4395. Hmm, I'll have to think about this one. On the one hand, one always wants to reference up to date RFCs. In this case, we're starting with RFC 3986 [2] which is current. As best I can tell, RFC 3986 continues to carry an explicit reference to RFC 2717. The point of this part of the SDW draft is to tell a story about >explicit< chains of reference starting with the current specification for URIs (which at present is 3986). So, switching to RFC 4395 would to a significant degree undercut the story. I'm tempted to leave it as is: the statement in SDW that RFC 3986 references RFC 2717 is true; it seems the best fix is to first revise or supplant RFC 3986 to point to RFC 4395, and if it's worthwhile at that point, correct the SDW finding accordingly. What do you think? Noah [1] http://www.ietf.org/rfc/rfc3023.txt [2] http://www.ietf.org/rfc/rfc3986.txt -------------------------------------- Noah Mendelsohn IBM Corporation One Rogers Street Cambridge, MA 02142 1-617-693-4036 --------------------------------------
Received on Friday, 16 January 2009 21:04:00 UTC