Subject: [netmod] default namespace in XPath

From: Ladislav Lhotka <[email-masked]>
Date: Wed, 03 Jun 2009 10:55:34 +0200

Hi,

I propose the following change to Sec. 6.4. I believe it is better to
admit a deviation from XPath 1.0 - in fact, adoption of an XPath 2.0
feature - rather than pretend that the trick with redefining the null
namespace URI is legal.

OLD
----------------------------------------------------------------------
   XPath expressions are evaluated in the context of the current node,
   with the namespace of the current module defined as the null
   namespace.  References to identifiers in external modules MUST be
   qualified with appropriate prefixes, and references to the current
   module and its submodules MAY use a prefix.
----------------------------------------------------------------------

NEW
----------------------------------------------------------------------
   XPath expressions are evaluated in the context of the current
   node. The namespace URI of the current module is used for any
   unprefixed node name appearing in an XPath expression. References
   to identifiers defined in external modules MUST be qualified with
   appropriate prefixes, and references to identifiers defined in the
   current module and its submodules MAY use a prefix.

   The above concept of default namespace is adopted from XPath 2.0
   [XPATH2.0]. While it is a deviation from XPath 1.0, it helps
   simplify XPath expressions in YANG. No ambiguity may ever arise
   because YANG node identifiers are always qualified names with a
   non-null namespace URI.
---------------------------------------------------------------------

Consequently, I propose to change the label for citing the XPath 1.0
spec to [XPATH1.0] and add the following reference:

[XPATH2.0]
           Berglund A., Boag S., Chamberlin D., Fernandez M. F.,
           Kay M., Robie J., and Simeon J.,
           "XML Path Language (XPath) 2.0", World Wide Web Consortium
           Recommendation REC-xpath20-20070123,
           <http://www.w3.org/TR/2007/REC-xpath20-20070123/>

Lada

-- 
Ladislav Lhotka, CESNET
PGP Key ID: E74E8C0C

---

From: Phil Shafer <[email-masked]>
Date: Wed, 3 Jun 2009 13:07:40 -0400

>feature - rather than pretend that the trick with redefining the null

-1 to this.  Defining the evaluation context is not a "trick".  If
it would, I would be against using it at all.

Thanks,
 Phil

---

From: Andy Bierman <[email-masked]>
Date: Wed, 03 Jun 2009 10:25:47 -0700

> it would, I would be against using it at all.

+1 on the -1 (0?)

IMO, if a reference to XPath 2.0 is added, it
will confuse people into thinking all of 2.0 is supported,
not just 1 tiny part.

>  Phil

Andy

---

From: Phil Shafer <[email-masked]>
Date: Wed, 3 Jun 2009 13:45:59 -0400

>+1 on the -1 (0?)

I oppose making this change.  It's not needed and makes the
draft less clear.

Thanks,
 Phil

---

From: "tom.petch" <[email-masked]>
Date: Wed, 3 Jun 2009 19:05:01 +0200

----- Original Message -----
From: "Ladislav Lhotka" <[email-masked]>
To: "NETMOD Working Group" <[email-masked]>
Sent: Wednesday, June 03, 2009 10:55 AM
Subject: [netmod] default namespace in XPath

> feature - rather than pretend that the trick with redefining the null

Sounds good.

Be aware, as I am:-), that namespaces are also described in the context of XPath
in
7.5.3 (must) and 7.19.5 (when)
but are not described in
7.15 (augment), 9.9.2 (path) and 9.13 (instance-identifier)
and whatever we end up with, I see and hear no reason why these five should
be treated differently, ie all use just the description in 6.4 or all include
additional text.

Tom Petch

---

From: Ladislav Lhotka <[email-masked]>
Date: Wed, 03 Jun 2009 21:46:59 +0200

> it would, I would be against using it at all.

You should then. Saying that "null namespace URI" is a normal
(non-null!) namespace URI is a very dirty trick. The default namespace
is NOT part of evaluation context in XPath 1.0.

XPath 2.0 has this

[Definition: Default element/type namespace. This is a namespace URI or
"none". The namespace URI, if present, is used for any unprefixed QName
appearing in a position where an element or type name is expected.]

In XPath 1.0, "none" is the only possibility and this is what "null
namespace URI" denotes.

Lada

-- 
Ladislav Lhotka, CESNET
PGP Key ID: E74E8C0C

---

From: Martin Bjorklund <[email-masked]>
Date: Thu, 04 Jun 2009 00:15:46 +0200 (CEST)

> is NOT part of evaluation context in XPath 1.0.

My interpretation of the arguments so far is that Lada doesn't
like the term "null namespace" and Phil and Andy thinks the reference
to XPath 2.0 is misleading.

So could we replace the current text with just the first of Lada's
paragraphs:

OLD

NEW

/martin

---

From: Phil Shafer <[email-masked]>
Date: Thu, 4 Jun 2009 01:04:41 -0400

>to XPath 2.0 is misleading.

I think we used this term to jibe with XPath:

    XPath fully supports XML Namespaces [XML Names]. Thus, the name
    of a node is modeled as a pair consisting of a local part and
    a possibly null namespace URI; this is called an expanded-name.
    The data model is described in detail in [5 Data Model].

But I think you are right that we should avoid this term.  It
isn't used as a complete term but as a "null" "namespace URI".

>So could we replace the current text with just the first of Lada's

The xslt spec defines the evaluation context as:

     In XSLT, an outermost expression (i.e. an expression that is
     not part of another expression) gets its context as follows:

     - the context node comes from the current node

     - the context position comes from the position of the current
     node in the current node list; the first position is 1

     - the context size comes from the size of the current node list

     - the variable bindings are the bindings in scope on the element
     which has the attribute in which the expression occurs (see
     [11 Variables and Parameters])

     - the set of namespace declarations are those in scope on the
     element which has the attribute in which the expression occurs;
     this includes the implicit declaration of the prefix xml
     required by the the XML Namespaces Recommendation [XML Names];
     the default namespace (as declared by xmlns) is not part of
     this set

     - the function library consists of the core function library
     together with the additional functions defined in [12 Additional
     Functions] and extension functions as described in [14
     Extensions]; it is an error for an expression to include a
     call to any other function

We should mimic parts of this text, but repair the fifth bullet to
read "the module's namespace will be used as the default namespace
is used to qualify any QName that has no prefix."

Something like:

In YANG, an outermost expression (i.e. an expression that is
not part of another expression) gets its context as follows:

- the context node is the current database node
- the context position comes from the position
  of the current node within the current node list;
  the first position is 1
- the context size comes from the size of the current node list
- the variable bindings are limited to $current, which is defined
  as the current node
- the set of namespace declarations are those which are imported
  in the current module or submodule, along with the prefixes under
  which they were imported;  this includes the implicit declaration
  of the prefix xml required by the the XML Namespaces
  Recommendation [XML Names]; the module's namespace will be used
  as the default namespace is used to qualify any QName that has
  no prefix

Thanks,
 Phil

---

From: Ladislav Lhotka <[email-masked]>
Date: Thu, 04 Jun 2009 09:09:33 +0200

> like the term "null namespace" and Phil and Andy thinks the reference

Rather, I don't like misinterpreting the following sentence from XPath
1.0 spec in the way that the "null namespace URI" can be arbitrarily
defined:

This is the same way expansion is done for element type names in start
and end-tags except that the default namespace declared with xmlns is
not used: if the QName does not have a prefix, then the namespace URI is
null (this is the same way attribute names are expanded).

> So could we replace the current text with just the first of Lada's

I am fine with this, but XML-savvy readers will notice that this is not
allowed in XPath 1.0, which YANG claims to rely on. So I thought it
would be useful to explain that this convention is perfectly OK in YANG
because all identifiers belong to a non-null namespace, so the ambiguity
between default and null namespace URI (which is why the above rule was
accepted in XPath 1.0) can never arise.

Lada

-- 
Ladislav Lhotka, CESNET
PGP Key ID: E74E8C0C

---

From: Martin Bjorklund <[email-masked]>
Date: Thu, 04 Jun 2009 09:20:06 +0200 (CEST)

> not part of another expression) gets its context as follows:

Can we simplify this - what is an expression that is part of another
expression in YANG?  

> - the context node is the current database node

Ok.

> - the context size comes from the size of the current node list

I must admit that I do not understand this.  What exactly is the
"current node list"?  Also, stating that the first position is 1 is
redundant, since that how it works in XPath.

> - the variable bindings are limited to $current, which is defined

We got rid of $current in favor of current(), so we should say that
the variable bindings are empty.

>   of the prefix xml required by the the XML Namespaces

No, we should not have the prefix 'xml' implicitly declared!

/martin

---

From: Martin Bjorklund <[email-masked]>
Date: Thu, 04 Jun 2009 09:29:14 +0200 (CEST)

> accepted in XPath 1.0) can never arise.

I agree with you; I also think it would be useful to state this.
Maybe slightly change the words to:

   The above concept of default namespace is adopted from XPath 2.0
   [XPATH2.0]. It helps simplify XPath expressions in YANG. No
   ambiguity may ever arise because YANG node identifiers are always
   qualified names with a non-null namespace URI.

I am not worried by having XPath 2.0 as a non-normative reference.

/martin

---

From: Phil Shafer <[email-masked]>
Date: Thu, 4 Jun 2009 09:38:31 -0400

>   qualified names with a non-null namespace URI.

I disagree, and see this as false.  We did not adopt this from
xpath-2.0.  We copied xslt's use of xpath, where xslt defines the
evaluation context for xpath expressions.  No one even noticed how
xpath-2.0 worked until much later.  We mimic xslt and xslt uses
xpath-1.0, so I'm completely surprised that this continues to
be seen as a sticking point.

Thanks,
 Phil

---

From: Phil Shafer <[email-masked]>
Date: Thu, 4 Jun 2009 09:34:40 -0400

>Can we simplify this - what is an expression that is part of another

 must foo/goo[name != "fish"];

The context being defined is that of the outermost expression
(goo), not the inner (name != "fish").  Note this is recursive,
but rarely used (foo/goo[zoo/moo[name == "fish"]]).

>redundant, since that how it works in XPath.

context size defines the value for "last()".

>the variable bindings are empty.

Doh!  My bad.

>No, we should not have the prefix 'xml' implicitly declared!

We should, since they say it's required for namespaces. ;^)

I've looked in rec-xml-names and don't see any use of "xml" as
a prefix.  It does say:

    Namespace constraint: Reserved Prefixes and Namespace Names

    The prefix xml is by definition bound to the namespace name
    http://www.w3.org/XML/1998/namespace. It MAY, but need not, be
    declared, and MUST NOT be bound to any other namespace name.
    Other prefixes MUST NOT be bound to this namespace name, and
    it MUST NOT be declared as the default namespace.

    The prefix xmlns is used only to declare namespace bindings and
    is by definition bound to the namespace name
    http://www.w3.org/2000/xmlns/. It MUST NOT be declared . Other
    prefixes MUST NOT be bound to this namespace name, and it MUST
    NOT be declared as the default namespace. Element names MUST
    NOT have the prefix xmlns.

I see xmlns (as in xmlns:junos="http://...") but don't see any
use of the xml prefix or the "http://www.w3.org/XML/1998/namespace"
namespace.

Am I missing something?  Should we ape XSLT even if we don't
follow the reasoning?  Rec-xml-names seems to say that it's
somehow vital to the operation of namespaces, but I don't
see it.

Thanks,
 Phil

---

From: Martin Bjorklund <[email-masked]>
Date: Thu, 04 Jun 2009 16:01:44 +0200 (CEST)

> but rarely used (foo/goo[zoo/moo[name == "fish"]]).

But this is how XPath works, so why do we have to state it again?

> context size defines the value for "last()".

Sure, but my question is what the "current node list" is.

> We should, since they say it's required for namespaces. ;^)

It's a predefined prefix in XML instance documents.  If it was
required for all XPath usages, it would have been specified as one
member of the prefix-to-uri map in the XPath spec.

/martin

---

From: Ladislav Lhotka <[email-masked]>
Date: Thu, 04 Jun 2009 16:12:48 +0200

> be seen as a sticking point.

No, it doesn't work like this in XSLT. Element names in XPath
expressions that carry no namespace prefix are considered to have the
null namespace URI and will not match elements in another (non-null)
namespace even if this namespace is declared as default (via xmlns) in
the XSL stylesheet.

That's why YANG XPath expressions will have to be transformed (explicit
prefixes added) before they can be used e.g. in Schematron.

Lada

-- 
Ladislav Lhotka, CESNET
PGP Key ID: E74E8C0C

---

From: Andy Bierman <[email-masked]>
Date: Thu, 04 Jun 2009 07:17:44 -0700

> context size defines the value for "last()".

context is recursive, e.g., "//*[2]".
The context size will be different in each subtree.
The ordering (depends on forward or reverse axis)
is associated with the match expression, not the document:

   (foo/goo[name != "fish"])[2]

>> the variable bindings are empty.

Vendors may want to use variable bindings.
They show up in XPath filtering, not just must/when.
We should say it is out of scope how the bindings get set,
and in the future, there may even be standard variables.
If we say the list is empty in YANG 1.0, we will never
be able to change it.

> use of the xml prefix or the "http://www.w3.org/XML/1998/namespace"

I think some XSD validators will hardwire the 'xml' prefix,
and complain if you explicitly import '1998' into the XSD.

Andy

---

From: Phil Shafer <[email-masked]>
Date: Thu, 4 Jun 2009 10:58:48 -0400

>But this is how XPath works, so why do we have to state it again?

I would just follow the way XSLT handles it, so yes, state it
again.  We are defining the context for the outermost expression.

>Sure, but my question is what the "current node list" is.

Hmm...  I guess for us, there is none.  None of our expressions
are evaluated against a node set, so the position isn't an
issue for the evaluation context.  It would still matter
in the other contexts (the non-outermost expression), where
saying foo[goo[1] == 'fish'] makes position important.

>member of the prefix-to-uri map in the XPath spec.

Rec-xml-names says they are predefined, and xslt refers to
that.  I'd mimic xslt again.

Thanks,
 Phil

---

From: Ladislav Lhotka <[email-masked]>
Date: Thu, 04 Jun 2009 17:13:05 +0200

Joel M. Halpern píše v Čt 04. 06. 2009 v 10:52 -0400:
> I am not sure that I understood you.
> Let me try to paraphrase, in a pure XML context.
> In an XPath expression (in XSLT, and maybe elsewhere?) the default 
> namespace is irrelevant.  There i sno way to refer to an element in the 
> default namespace (assuming that the default namespace has been 
> declared) excpet my explicitly using the non-default namespace 
> designator for that particular namespace.
> 
> I.e. The default namespace declaration has no effect on the meaning of 
> terms in the XPath expression.
> 

Yes, this is correct. I guess every XSLT developer has been bitten by
this behaviour and it is a mandatory entry in every XSLT FAQ.

> Is that the way it works?  (I believe that is indeed the case for 
> attributes.  I had not realized it was the case for XPath element names.)

This is just what the XPath spec says:
"if the QName does not have a prefix, then the namespace URI is null
(this is the same way attribute names are expanded)".

Lada

> Yours,
> Joel
> Ladislav Lhotka wrote:
-- 
Ladislav Lhotka, CESNET
PGP Key ID: E74E8C0C

---

From: "tom.petch" <[email-masked]>
Date: Fri, 5 Jun 2009 10:47:42 +0200

Martin

I am (very much with) Lada on this and I am happy with your formulation herein
(and apologies that I am never going to be right up with the cut and thrust of
e-mails threads such as this.  My way of working is more of a considered
response some time later).

Null is well defined is XPath (and XSD) and so I think the wording in -05 is not
as respectful of X... as it could be and that your text is an improvement.

I think it good to have a informative reference to XPath 2.0.

Tom Petch

---

From: "tom.petch" <[email-masked]>
Date: Fri, 5 Jun 2009 11:52:04 +0200

----- Original Message -----
From: "Martin Bjorklund" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>
Sent: Thursday, June 04, 2009 4:01 PM

> Sure, but my question is what the "current node list" is.

Martin,

Not sure where you have got to on this, but stepping back, an XPath 1.0 context
consists of:
a context node, a pair of positive integers (context position and context size),
a set of variable bindings, a function library, a set of namespace declarations.

During evaluation, the context node, position and size can vary, the others do
not. Predicates change position and size; expressions change the context node.

A step in a location path selects a set of nodes each of which is then is then
used in the evaluation of the next step (eg all those in a YANG list{}).  I do
not see the term 'current node list' in XPath, only in XSLT, but take it to be
that set, that sequence of nodes.

XPath 2.0 has a better description but has generalised context node to context
item.

I do not think that XSLT gets the XPath terminology quite right ('outer
expression', 'current node list', ..) .  XQuery does it better.

Tom Petch