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

On Friday, October 24, 2003, 3:43:08 PM, Elliotte wrote:


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

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

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

Thanks for the pointer, which indeed merely says that parens and
quotes are "hard to parse", a statement easily rebutted by example.

I was responding to what Roy said on the telcon, which seemed to
bexactly that parens should not be used in fragids.

ERH> It's not that the parentheses are illegal in fragment IDs. In fact,
ERH> they're not illegal as RFC 2396 makes clear.

Okay (though I would need to check up 2396bis to fully agree).

ERH> It's the other
ERH> characters allowed in XPath like < and > and the square brackets [
ERH> and ].  To be honest using < and > is a design flaw in XPath that
ERH> affects XSLT too. However, for XPointer these are only an issue with
ERH> the xpointer() scheme, not with the entire XPointer framework.

Okay, that is useful clarification.

ERH> There's one more problem. The ^ character that XPointer uses to 
ERH> escape unbalanced parentheses is also disallowed.

Although disallowed characters can be percent hexified.

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

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

I agree that its unfortunate that two parts of a URI are called the
'scheme'. Although, it used to be that fragids were not part of the
URI but were part of the URI reference, so the chance of ambiguity was
less.

ERH> There's one more point, "focuses on mechanical identification of XML
ERH> elements (fragile and media-type-specific) rather than the content
ERH> (section heading, paragraph number, paragraph text, etc.)" which I'm
ERH> 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/

ERH> Please remember that http://www.w3.org/TR/xptr-xpointer/ is not a
ERH> recommendation, only a working draft.

Oops my bad.

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

This would also mean that SMIL 2, SVG are not broken either. Naturally
i am pleased at this.

ERH> Going forward, I suggest a 1.1 version of the XPointer framework that
ERH> explicitly disallows parentheses from pointer parts.

On the other hand, that seems to give knock-on effects on everything
else that uses it. If the parens are not illegal, I don't see the
value in a 1.1

ERH> This would mean raw XPath could no longer, even in theory, be used
ERH> for XPointer. Honestly, I'm not sure that's a bad thing.

Seems a pity for the xpath1() scheme, though.

ERH>  The effort
ERH> to unify XSLT and XPointer addressing syntax via XPath may have been
ERH> a mistake. XPath may not be very suitable for use with XPointer. The
ERH> element scheme does a lot of what people need. A simpler syntax along
ERH> the lines of XSLT match patterns, perhaps without predicates, might
ERH> work better for XPointer. But this could all be explored later. I
ERH> don't think it should stand in the way of saying that the xpointer()
ERH> scheme is broken now.



-- 
 Chris                            mailto:chris@w3.org

Received on Friday, 24 October 2003 12:43:11 UTC