[Bug 6131] [XPath 2.1] Requirement: context-free paths

http://www.w3.org/Bugs/Public/show_bug.cgi?id=6131


John Snelson <john.snelson@oracle.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |john.snelson@oracle.com




--- Comment #7 from John Snelson <john.snelson@oracle.com>  2009-07-08 11:42:50 ---
(In reply to comment #6)
> Comment #4 suggests syntax that looks reasonable enough if you approach the
> problem from an XQuery perspective. But in proposing this approach, we were
> looking at the problem primarily from the point of view of XPath use cases, and
> the syntax feels very clumsy at the XPath level. For a start, it introduces
> curly braces to XPath for the first time, which is a significant disadvantage
> for some of the environments where XPath is embedded (for example, XSLT) -
> though not necessarily insuperable.

I'm sensitive to the problems the use of curly braces would have for attribute
value templates in XSLT. However as the XSLT 2.0 spec notes, implementors
already have to worry about curly braces in string literals and comments.
Having to be concerned with them in another place is not such a big change,
since implementations are already having to parse the XPath to correctly find
the end of the embedded expression.

> A major part of the rationale for introducing an EQName syntax, however, was
> that it could be widely adopted anywhere that QNames are currently used - not
> only in XPath. For example, some XML vocabularies such as XSLT and XSD make
> wide use of QNames-in-content in contexts other than XPath, and these share the
> same requirement to be written in a context-free way. Obviously adoption of
> EQName syntax would be on a case-by-case basis, but including it in XPath as a
> first step, and in XSLT soon after, would set a precedent that I think other
> specs might well choose to follow.

That's an interesting idea, and certainly ambitious. I can see the use case for
this in XQuery and especially in XSLT (not poluting the in-scope namespaces).
Variable, function and template names could benefit in this regard, as well as
NodeTests.

In the past I've considered a 'using function namespace "http://foo";'
construct in XQuery to also help resolve function names.

> An alternative that was considered was to use Clark names in the format
> {uri}local. These are already used in a number of interfaces, for example in
> Java APIs. If the only objection to the proposal is the use of backtick, then
> perhaps we should consider using Clark names instead. They have the advantage
> of familiarity and precedent. The reason I recommended using backtick-syntax
> instead was that the curly braces cause problems in certain syntactic contexts.
> In particular they cause problems when used in an XSLT attribute value
> template, especially if the left-curly is the first character.

I would think that using Clark names has a better chance of success in the
wider community. I would be ok with that change - I think it's the backticks
that I really don't like.

A bigger issue with using curly braces in Clark names is that they are already
used extensively in XQuery and XSLT, and might well find many more uses in the
future. I imagine that we'd need to insist on some lexical conventions to
restrict these tokens - maybe insisting on no whitespace inside the token
around the braces would be reasonable.


-- 
Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.

Received on Wednesday, 8 July 2009 11:43:01 UTC