Re: [Minutes] 20 Oct 2003 TAG teleconf (abstractComponentRefs-37, URI Syntax, RFC 3023)

At 4:52 AM +0200 10/24/03, Chris Lilley wrote:

>I was troubled by Roy's assertion that parens in fragids were illegal
>and contrary to the BNF for a URI.

That's not really what Roy said, at least in his original post which 
you can read here:

http://lists.w3.org/Archives/Public/www-xml-linking-comments/2002OctDec/0039.html

It's not that the parentheses are illegal in fragment IDs. In fact, 
they're not illegal as RFC 2396 makes clear. It's the other 
characters allowed in XPath like < and > and the square brackets [ 
and ].  To be honest using < and > is a design flaw in XPath that 
affects XSLT too. However, for XPointer these are only an issue with 
the xpointer() scheme, not with the entire XPointer framework. 
There's one more problem. The ^ character that XPointer uses to 
escape unbalanced parentheses is also disallowed.

Roy did raise an issue about the use of "balanced quotes inside 
balanced parens with encapsulated functions".  He's got a point, but 
again this point only really applies to the xpointer() scheme, not to 
the framework, bare name XPointers, or the element() scheme.

He also objects to the overloading of the term "scheme" which, while 
accurate, does not strike me as an architectural issue.

There's one more point, "focuses on mechanical identification of XML 
elements (fragile and media-type-specific) rather than the content 
(section heading, paragraph number, paragraph text, etc.)" which I'm 
not sure I understand.

>This was being discussed in the
>context of WSDL fragids; I pointed out that if the TAG as a whole took
>the position that these were architecturally broken, then we were
>saying that the following W3C Recs were broken:
>
>http://www.w3.org/TR/xptr-framework/
>http://www.w3.org/TR/xptr-element/
>http://www.w3.org/TR/xptr-xmlns/
>http://www.w3.org/TR/xptr-xpointer/
>http://www.w3.org/TR/smil20/
>http://www.w3.org/TR/SVG/

Please remember that http://www.w3.org/TR/xptr-xpointer/ is not a 
recommendation, only a working draft. That's clearly the one with the 
biggest problems which is why it's not a rec.

It seems to me that a plausible way forward is to say that the 
xpointer() scheme is architecturally broken but not say the same 
thing for the framework or the element scheme. This is not a big deal 
because the xpointer() scheme is not a Rec.

Going forward, I suggest a 1.1 version of the XPointer framework that 
explicitly disallows parentheses from pointer parts. This would 
simultaneously allow us to remove the need to use the ^ for escaping 
unbalanced parentheses.

This would mean raw XPath could no longer, even in theory, be used 
for XPointer. Honestly, I'm not sure that's a bad thing. The effort 
to unify XSLT and XPointer addressing syntax via XPath may have been 
a mistake. XPath may not be very suitable for use with XPointer. The 
element scheme does a lot of what people need. A simpler syntax along 
the lines of XSLT match patterns, perhaps without predicates, might 
work better for XPointer. But this could all be explored later. I 
don't think it should stand in the way of saying that the xpointer() 
scheme is broken now.
-- 

   Elliotte Rusty Harold
   elharo@metalab.unc.edu
   Processing XML with Java (Addison-Wesley, 2002)
   http://www.cafeconleche.org/books/xmljava
   http://www.amazon.com/exec/obidos/ISBN%3D0201771861/cafeaulaitA

Received on Friday, 24 October 2003 09:44:05 UTC