W3C home > Mailing lists > Public > www-tag@w3.org > January 2009

Re: Near final draft of TAG finding on the Self-Describing Web

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
Message-ID: <OFCA3E93E3.83C1200D-ON85257540.00727DAD-85257540.007395C9@lotus.com>

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?


[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
Received on Friday, 16 January 2009 21:04:00 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:56:26 UTC