Re: [xsl] Proposed syntax for namespace binding in XPath

Subject: Re: [xsl] Proposed syntax for namespace binding in XPath
From: "Dimitre Novatchev" <dnovatchev@xxxxxxxxx>
Date: Sat, 31 Mar 2007 19:26:46 -0700
On 3/31/07, Michael Kay <mike@xxxxxxxxxxxx> wrote:
I'd like to solicit reactions to a proposal to define an informal standard
for binding namespaces in strings containing XPath expressions.

I tried only briefly to evaluate this proposal and could not find essential problems with it.

What I would like added is the ability to define global bindings
(define once, use always thereafter). Globally defined namespace
bindings could have the form:

  (:# xmlns=http://default/uri xmlns:p=http://other/uri #:)

(:# xmlns=http://default/uri xmlns:p=http://other/uri #:)

# :)

that is one default namespace and a (possible) list of namespaces bound to prefixes.

I think it would be more clear if we do *not* allow any XPath
expression to follow immediately a  global set of namespace bindings
(as part of the same definition).

Once global bindings have been defined, it would not be necessary to
define them again and again at the start of every new XPath

Using the same approach it is easily possible to define *named sets of bindings* The global bindings above are a special case of a named set having the name "GLOBALS".

or even  hierarchically-named sets of bindings -- if we use nested
XPath comments.

Finally, it may be a good idea to allow reading such sets of bindings
from files and thus share easily namespace bindings that have already
been created for us by more clever or powerful people.

-- Cheers, Dimitre Novatchev --------------------------------------- Truly great madness cannot be achieved without significant intelligence. --------------------------------------- To invent, you need a good imagination and a pile of junk ------------------------------------- You've achieved success in your field when you don't know whether what you're doing is work or play

I see a lot of people using XPath from Java and also using saxon:evaluate to evaluate dynamically-constructed XPath expressions from XSLT or XQuery. One of the difficulties with such interfaces has always been that defining the namespace bindings is messy - in fact, in saxon:evaluate, it can't be done dynamically at all.

Clearly a vendor-defined API can take as input some string that contains a
set of namespace bindings followed by an XPath expression. This doesn't
violate XPath conformance; it just means that the string passed to the API
contains an XPath expression embedded in something else. Hopefully other
systems that offer XPath APIs will follow suit, and we can establish an
informal standard rather along the lines of the Clark notation for expanded
QNames "{uri}local".

In choosing a syntax I'd like something that falls back to standard XPath if
there are no namespace bindings, and where it's very easy to spot that
namespace bindings are present if this is the case. I think that in the
XPath house-style, it should also be less wordy than the XQuery prolog which

declare default element namespace x = "uri";

I would also like something that can be written in an XML attribute, so
characters such as "<" (and ideally quotes) should be avoided.

XPointer has a mechanism that's one possible candidate: the xmlns() scheme:

An example is


or in context,


There are several disadvantages to adopting this directly. It doesn't allow
the default namespace to be bound; it's not easily distinguishable from a
function call; it can't handle a URI containing an unpaired right bracket;
and it doesn't fall back to pure XPath when there are no bindings.

The syntax I'm thinking of using is:

(:# xmlns=http://default/uri xmlns:p=http://other/uri #:) xpath-expression

Using a special comment has the advantage that XPath processors that don't
understand the notation will ignore it (though I freely admit that
"meaningful comments" have their drawbacks). It avoids use of quotes which
makes it easy to embed in an XML attribute, and it uses space to delimit the
URI - although there is no absolute ban on having a space in a namespace
URI, there are already plenty of things that will break if you do it, so
it's unlikely to cause any new problems.

Michael Kay

Current Thread