Subject: [netmod] yang-06 XPath issues

From: "tom.petch" <[email-masked]>
Date: Fri, 26 Jun 2009 15:33:23 +0200

I like the changes in the coverage of XPath in -06, I find this much clearer and
I think that the coverage of unprefixed names most decorous.

I think though that there is a glitch in "augment"

'    o  The context node is the target node in the schema tree.'

seems circular since the whole point of the XPath is to define an augment's
target node.

I think that the two cases need splitting.

"augment" at the top level uses an absolute XPath expression so the initial
context node is irrelevant (as far as I can know).  We probably should say what
the context node is but I suspect it has to be the first ancestor schema node
except that there isn't one and saying that might make people wonder why does it
matter:-(

"augment" as a substatement of "uses" (not really 'in' as the text has it) has
as context node for the relative XPath expression the grouping which is the
argument of the "uses".

Lada did say last month
'The context is quite clear for "augment", but the document is the
corresponding schema tree, unlike the other uses of XPath.'
so he may have a better idea of how to word it.

For this, and for the other uses of XPath, we should have examples.  The
discussions about this over several months have shown uncertainty, particularly
about just what an absolute XPath expression looks like, what comes after the
first solidus, but also about when predicates and functions are and are not
allowed and about the names without prefixes.  I am thinking of a relative and
an absolute example with predicates and functions for each of the five cases,
where those options are allowed ie 9 examples in all.

Tom Petch

---

From: Ladislav Lhotka <[email-masked]>
Date: Mon, 29 Jun 2009 09:30:21 +0200

> I think that the two cases need splitting.

Yes, and IMO two different keywords are needed, otherwise the
specification will be quite confusing. It has been already agreed to
change the keyword for "augment under uses" but the problem apparently
is that no suitable alternative has been found yet.

> except that there isn't one and saying that might make people wonder why does it

Perhaps the context node could be the root node (in XPath sense)?

> as context node for the relative XPath expression the grouping which is the

I think the context node should rather be the data node under which
'uses' appears, so that the namespace of the nodes appearing in the
XPath expression is fixed - data nodes defined in a grouping get a
namespace only after the grouping is expanded.

> so he may have a better idea of how to word it.

I meant that in the case of 'augment' (both variants) there was no doubt
about the document the expression applies to.

> where those options are allowed ie 9 examples in all.

This would help but the source for the uncertainty will remain, which is
the sheer number of different ways and contexts in which XPath or
quasi-XPath is used in YANG. I am not aware of any other XML-related
technology that stretches poor XPath 1.0 this far.

Lada
 
-- 
Ladislav Lhotka, CESNET
PGP Key ID: E74E8C0C

---

From: Martin Bjorklund <[email-masked]>
Date: Mon, 29 Jun 2009 10:15:55 +0200 (CEST)

> Perhaps the context node could be the root node (in XPath sense)?

Ok.

> 'uses' appears

Yes.

So how about this:

   The "augment" XPath expression is conceptually evaluated in the
   following context, in addition to the definition in Section 6.4.1:

   o  If the "augment" statement is on the top-level, the context node
      is the XPath root node.  The XPath root node has all top-level
      schema nodes in all modules as children.

   o  If the "augment" statement is a substatement to "uses", the
      context node is the node in the data tree for which the "uses"
      statement is defined.

/martin

---

From: Ladislav Lhotka <[email-masked]>
Date: Mon, 29 Jun 2009 10:46:53 +0200

>       schema nodes in all modules as children.

The document should also be specified:

   o  If the "augment" statement is on the top-level, the context node
      is the XPath root node of the overall schema tree, which is the 
      union of schema trees of the local module and all imported 
      modules. The XPath root node has all top-level schema nodes in 
      all modules as children.

>       context node is the node in the data tree for which the "uses"

But wait, the expressions in 'augment' may contain choice nodes, so it
is the schema tree and not the data tree that the expression addresses.

BTW, the nodes in both the schema and data tree are in the same
namespace, right?

Lada

-- 
Ladislav Lhotka, CESNET
PGP Key ID: E74E8C0C

---

From: Martin Bjorklund <[email-masked]>
Date: Mon, 29 Jun 2009 10:53:33 +0200 (CEST)

Ok.

> is the schema tree and not the data tree that the expression addresses.

Yes, copy&paste error.  s/data tree/schema tree/  done.

Yes.

/martin

---

From: Andy Bierman <[email-masked]>
Date: Mon, 29 Jun 2009 05:13:27 -0700

>       context node is the node in the data tree for which the "uses"

what if the uses-stmt is itself within a grouping?

> /martin

Andy

---

From: Ladislav Lhotka <[email-masked]>
Date: Mon, 29 Jun 2009 14:29:32 +0200

> what if the uses-stmt is itself within a grouping?

Very good question! In this case it would be natural to follow the
chameleon-like nature of groupings, but what if any of the nodes in the
augment argument contained explicit namespace prefixes?

Strictly speaking, the nodes defined inside a grouping have the null
namespace URI (= are not assigned to any namespace) and so there indeed
is an ambiguity between the default/local namespace URI and the null
URI.

Lada

-- 
Ladislav Lhotka, CESNET
PGP Key ID: E74E8C0C

---

From: Martin Bjorklund <[email-masked]>
Date: Mon, 29 Jun 2009 14:56:55 +0200 (CEST)

> augment argument contained explicit namespace prefixes?

The context node (.) should have as its children only the children of
the grouping statement.  This uses statement is not allowed to refer
to any node outside the grouping.  Do we have to invent some artifical
context node?

> is an ambiguity between the default/local namespace URI and the null

Hmm.. I'm not sure I follow... Isn't this example correct in your
opinion:

   module x {
     prefix x;
     ...

     grouping bar {
       container a { ... }
     }

     grouping foo {
       uses bar {
          augment "x:a" {  // legal reference to a??
            leaf z { ... }
          }
       }
     }
  }

/martin

---

From: Ladislav Lhotka <[email-masked]>
Date: Mon, 29 Jun 2009 15:50:56 +0200

> Hmm.. I'm not sure I follow... Isn't this example correct in your

Yes, this is the problem: I don't think 'a' is in the namespace of
module 'x' - for sure it isn't if 'foo' is used in another module.
Groupings don't contribute to the schema tree, so if we wanted to have
the context node for 'augment-uses' in the schema tree, this could only
be after all the groupings are expanded and namespaces assigned.

It seems we have to define the context node to be the grouping (as Tom
suggested) and treat all nodes inside the grouping as having no
namespace. So in your example, 'augment "a"' would work but
'augment "x:a"' wouldn't match anything.

When the nodes defined in a grouping are eventually installed in the
schema tree, they assume the namespace of the module that used the
grouping, and this should be true also for nodes appearing in XPath
expressions - consider

must "a/z > 1";

inside grouping foo in your example. Having "x:" or other NS prefixes in
that expression would be a nonsense.

Lada

-- 
Ladislav Lhotka, CESNET
PGP Key ID: E74E8C0C

---

From: Andy Bierman <[email-masked]>
Date: Mon, 29 Jun 2009 07:28:13 -0700

> be after all the groupings are expanded and namespaces assigned.

Prefixes in grouping bar and foo are evaluated in module x.
That's how groupings are defined.  Your XPath code needs
to be clever enough to check for well-formed XPath in
the grouping, bind the prefixes to namespace IDs in
the grouping, but nothing else.

Then your clever XPath code knows (when the final cooked
objects are put into place), that it is okay to validate
the objects for real, using the previous prefix mappings.

We went though all this when 'import-by-revision' was discussed.
You better evaluate your prefixes in the right place, or
you might pick up the wrong module or the wrong version.

> 'augment "x:a"' wouldn't match anything.

no -- all the 'uses' within the grouping 'foo will be evaluated
before any 'uses foo' statement is itself evaluated.  If you write the code
correctly, everything just works.  You can't follow it with
the naked eye sometimes, but so what.

All objects (all the time) are defined within a module namespace,
and there is a valid prefix that can be used at any time.

Andy