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

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

           Summary: [XPath 2.1] Requirement: context-free paths
           Product: XPath / XQuery / XSLT
           Version: Recommendation
          Platform: PC
        OS/Version: Windows NT
            Status: NEW
          Severity: enhancement
          Priority: P2
         Component: XPath 2.1
        AssignedTo: jonathan.robie@redhat.com
        ReportedBy: mike@saxonica.com
         QAContact: public-qt-comments@w3.org


There's a common requirement to generate paths whose evaluation is context
free, that is, paths that don't require external binding of namespace prefixes.
For an example, see

http://lists.w3.org/Archives/Member/w3c-xsl-wg/2008Sep/0099.html

(member-only link)

Other use cases include XPath expressions contained in XML documents for
dynamic evaluation of business rules.

It's possible to use XQuery instead of XPath, in which case you can bind
namespaces in the query prolog, but that's not particulary convenient for
people wanting to generate paths, as it means all the namespaces must be known
at once, and distinct prefixes need to be allocated. Also, XPath
implementations are typically smaller than XQuery implementations.

One approach would be to define some kind of internal syntax for binding
prefixes within an XPath expression. This could be based on the XPointer syntax
or the XQuery syntax. There are two disadvantages with this approach: (a)
neither of these existing syntaxes blends well into XPath (and it would be a
shame to invent a third), and (b) it still leaves the software that generates
the path with the unnecessary job of finding all the namespace URIs up-front
and inventing unique prefixes for them. Using the URI "inline" is verbose and
perhaps takes fractionally longer to parse, but for many applications this
simply doesn't matter.

The proposal is therefore to extend the syntax so that 

(1) all the places in the grammar that currently refer to QName refer instead
to EQName. In XPath these constructs are NameTest, VarName, FunctionCall,
AtomicType, AttributeName, ElementName, TypeName

(2) the syntax for EQName is

EQName := QName | ExpandedName

ExpandedName := DelimitedURI NCName /* ws:explicit */

DelimitedURI := '`' (EscapeTick | [^`])* '`'

EscapeTick := "``"

I have proposed the "backtick" (x60 grave accent) as the delimiter in
preference to the more familiar curly braces (known as Clark notation) to avoid
confusion, if not technical ambiguity, with other uses of curly braces in XSLT
and XQuery. The backtick is not currently used in XSLT or in XQuery and it is
also one of the few characters that cannot legally appear in an IRI;
nevertheless I have taken the precaution of allowing it to be escaped by
doubling. It's also a rather unattractive character because of its poor
legibility, which doesn't matter for the target use case of machine-generated
XPaths, but means that we aren't using a character that we would want to save
for a greater role in the future. I originally considered proposing non-ASCII
characters, perhaps chevrons, but all such characters are allowed in IRIs.

If an EQName contains neither a prefix nor a DelimitedURI then it denotes a
name in the default namespace (for example the default namespace for elements
and types). If it starts with an empty DelimitedURI, for example ``book, then
it denotes a name in no namespace. (This particular notation might prove
popular even for hand-written XPath). 

This proposal is specifically for XPath 2.1 but I would imagine XQuery 1.1 will
want to remain compatible. I would recommend allowing EQName in place of QName
in all places in XQuery except where XML syntax is being mimicked, that is, in
direct element and attribute constructors.

(I would actually like to see this notation available in the lexical space of
the xs:QName data type, and even in XML syntax for writing element and
attribute names. But getting everyone to agree might not be trivial!)

For XSLT, similar issues of context-sensitivity apply in two situations:
generated stylesheets, and QNames used at run-time to refer to objects such as
keys, decimal formats, output formats, and system property names. If this
proposal is accepted I will follow up with an XSLT proposal to allow EQNames in
such contexts.


-- 
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, 1 October 2008 09:18:06 UTC