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: Mon, 19 Jan 2009 18:22:22 -0500
To: Mark Baker <mark@coactus.com>, Larry Masinter <masinter@adobe.com>
Cc: www-tag@w3.org, connolly@w3.org
Message-ID: <OFB1E1E3C1.10C41882-ON85257543.007F9D74-85257543.008064B8@lotus.com>
First, an apology.   When this thread first came in I read it too quickly 
and thought it was about the RDFa stuff that's later in the 
Self-describing Web draft.  So, my suggestion that we the TAG have 
discussed this before is more false than true, and I apologize for that. I 
agree that, unfortunately, the issue you've raised is substantive and 
can't be danced around.

I don't want to drop all of section 4.2.3, because the story it tells 
about URI-based extensibility is as much to motivate designers of new 
languages as to explain how XML itself can be used.  Furthermore, XML 
itself can be used in this dynamically extensible way, as long as it is 
served with some (as yet not standardized) media type or in some other 
context where the semantics are known.  So, I don't want to lose those 
lessons, which are the key ones.  To try and resolve this, I've drafted a 
proposed alternative version of section 4.2.3.  If you could review it 
ASAP I would be grateful, as we have a teleconference scheduled for 
Thursday, and there is a serious effort to try and move this finding 
forward now, before we have new members to bring up to speed on all the 
old discussions.

The new text is available at [1], with diffs from the previous 
(problematic) text at [2].  I'd be very grateful for both of your thoughts 
on this.  Does this resolve the concern?  Thank you.

Noah

[1] http://www.w3.org/2001/tag/doc/selfDescribingDocuments-3023.html
[2] 
http://www.w3.org/2007/10/htmldiff?doc1=http%3A%2F%2Fwww.w3.org%2F2001%2Ftag%2Fdoc%2FselfDescribingDocuments.html&doc2=http%3A%2F%2Fwww.w3.org%2F2001%2Ftag%2Fdoc%2FselfDescribingDocuments-3023.html#XMLSpecs

--------------------------------------
Noah Mendelsohn 
IBM Corporation
One Rogers Street
Cambridge, MA 02142
1-617-693-4036
--------------------------------------








Mark Baker <mark@coactus.com>
Sent by: www-tag-request@w3.org
01/17/2009 11:31 AM
 
        To:     noah_mendelsohn@us.ibm.com
        cc:     www-tag@w3.org
        Subject:        Re: Near final draft of TAG finding on the 
Self-Describing Web



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 Monday, 19 January 2009 23:23:06 GMT

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