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

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

From: Mark Baker <mark@coactus.com>
Date: Sat, 17 Jan 2009 11:31:03 -0500
Message-ID: <e9dffd640901170831u73b6195age66ab82a8d3b411b@mail.gmail.com>
To: noah_mendelsohn@us.ibm.com
Cc: www-tag@w3.org

On Fri, Jan 16, 2009 at 4:04 PM,  <noah_mendelsohn@us.ibm.com> wrote:
> 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:

Oh, I didn't realize you'd had this discussion before.

> "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."

Right.  That's a paragraph that Larry and I worked on together in
response to my raising exactly this issue.  It wasn't as clear as I
would have liked, but it's all we could agree upon.  Its intent, from
my POV, was to serve as a warning - through the use of the word
"might" - to those who might assume that publishing an XML document as
application/xml would necessarily be interpreted the same way as if
the format-specific media type were used.

> 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.

Work was started on 3023bis a few years ago, but there wasn't enough
interest in it.

But there is ambiguity in practice with such an interpretation of
3023, in that XML language designers aren't required to ensure that
the root namespace is their own, and indeed some haven't.  Two
examples;

http://www.w3.org/TR/xslt#result-element-stylesheet
http://www.w3.org/TR/rdf-syntax-grammar/#start

And then there's the surprisingly large number of languages which
don't even use namespaces.

>> 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?

I suppose that it would require explaining what "obsoletes" means to
readers, so ok, we can leave it as is.

Mark.
Received on Saturday, 17 January 2009 16:31:37 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 26 April 2012 12:48:11 GMT