Subject: [netmod] XPath expressions in must

From: Ladislav Lhotka <[email-masked]>
Date: Mon, 04 Aug 2008 12:26:54 +0200

Hi,

here is the relevant text from Section 2.3 of XPath 1.0 recommendation
(http://www.w3.org/TR/xpath#node-tests):

"if the QName does not have a prefix, then the namespace URI is null"

The YANG draft says:

"The null namespace is defined to be the namespace of the current
module".

I understand this was an attempt to avoid the XPath requirement to write
explicit namespace prefixes but IMO it is not acceptable. It is the same
like defining empty set to contain something. Null namespace means NO
namespace.

>From the practical POV, the XPath expressions found in must statements
will never work (unmodified) in validation tools such as XSLT
processors.

Therefore, I think it is absolutely necessary to follow the XPath spec
and remove the redefinition of null namespace. This means that node
names in must expressions will always have to have a NS prefix.

Lada

-- 
Ladislav Lhotka, CESNET
PGP Key ID: E74E8C0C

_______________________________________________
netmod mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/netmod

---

From: Andy Bierman <[email-masked]>
Date: Mon, 04 Aug 2008 06:54:21 -0700

> names in must expressions will always have to have a NS prefix.

Phil suggested that the YANG compiler can add the missing prefix
back into the expression, before processing it with XSLT.
Since XSLT cannot possibly process a 'raw' YANG file at all,
this seems reasonable.

I'm not sure you understand the purpose of the
human-friendly language form.  We either teach one tool
how to adapt to human needs, or we teach all the humans
how to adapt to the the tool's needs.

> Lada

Andy

---

From: Ladislav Lhotka <[email-masked]>
Date: Mon, 04 Aug 2008 16:35:01 +0200

> Since XSLT cannot possibly process a 'raw' YANG file at all,

Yes, I suggested that too, but parsing logic for XPath expressions would
be another complexity to be added to the YANG parser.

> how to adapt to the the tool's needs.

I understand it very well. However, if the YANG draft refers to XPath,
then it has to be XPath - and part of its 1.0 standard is this handling
of namespaces, whether you like it or not. The other option is to define
the syntax of must expressions in the YANG draft and call it something
else.

So my point is than it's a problem for YANG specification as well.

Lada

-- 
Ladislav Lhotka, CESNET
PGP Key ID: E74E8C0C

---

From: "Lahdensivu, Mikko (NSN - FI/Tampere)" <[email-masked]>
Date: Mon, 4 Aug 2008 17:37:31 +0300

Hi,

>Phil suggested that the YANG compiler can add the missing 
>prefix back into the expression, before processing it with XSLT.
>I'm not sure you understand the purpose of the human-friendly 
>language form.  We either teach one tool how to adapt to human 
>needs, or we teach all the humans how to adapt to the the tool's needs.
>
>> Lada
>> 
>
>Andy
>

part of the "human-friendliness" of a language is also about how close
it is to existing languages. If it is close, it is easy for reader to
get confused about small, distinct behaviour. Integrating an existing
language, and modifying its rules slightly, can be worse than a language
that is more clearly distinct from other languages.

I would consider that if you change the sub-language (xpath) trying to
optimize it for the main language (yang), you are requesting people to
actually adapt more to the language, than if you would do by keeping the
sub-language as it is.

The most important aspect of human-friendliness of a language is that
people understand it correctly.

Also, I hope that by "one tool" you mean just the language itself, not
that there wouldn't be multiple independent sets of tools around Yang,
which have to, like the people, adapt to the language.

Mikko

---

From: Balazs Lengyel <[email-masked]>
Date: Mon, 04 Aug 2008 15:17:43 +0200

I vote for Andy's interpretation.
Balazs

-- 
Balazs Lengyel                       Ericsson Hungary Ltd.
TSP System Manager
ECN: 831 7320                        Fax: +36 1 4377792
Tel: +36-1-437-7320     email: [email-masked]
_______________________________________________
netmod mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/netmod

---

From: Ladislav Lhotka <[email-masked]>
Date: Mon, 04 Aug 2008 16:54:40 +0200

> I vote for Andy's interpretation.

Mikko told it all.

Cheers, Lada

-- 
Ladislav Lhotka, CESNET
PGP Key ID: E74E8C0C

---

From: Andy Bierman <[email-masked]>
Date: Mon, 04 Aug 2008 07:55:04 -0700

> So my point is than it's a problem for YANG specification as well.

It already is something else.
YANG XPath has 'extra features' right?

Buried in the ABNF:

    this-variable-keyword  = '$this'

There is no normative text anywhere for '$this'.

 From 7.5.2:

    The XPath expression is conceptually evaluated in the following
    context:

    o  The context node is the node in the data tree for which the "must"
       statement is defined.

    o  The accessible tree is made up of all nodes in the data tree, and
       all leafs with default values.

    o  The set of namespace declarations is the set of all "import"
       statements' prefix and namespace pairs, and the "prefix"
       statement's prefix for the "namespace" statement's URI.

    o  The null namespace is defined to be the namespace of the current
       module.

    o  One variable "this", which is the context node, is defined.

YANG requires custom implementation of XPath already.
But the YANG parser requires lots of difficult custom code,
so maybe this is not a problem.

I suspect that "sort of using XPath 1.0" is not quite what
the WG thought we were doing.

Andy

---

From: Andy Bierman <[email-masked]>
Date: Mon, 04 Aug 2008 08:17:19 -0700

> that is more clearly distinct from other languages.

And yet, dozens if not hundreds of programming languages
start with existing concepts and syntax, and refine/improve
it in ways more suitable to their intended application.
Add YANG to that list.

At every step, the NETMOD WG is going to make design
trade-offs, based on the intended audience and application space.

IMO, operators who have not already learned XPath are not
going to care 1 way or another.  They will be too busy
skipping over all the must-stmts and other cryptic noise
they do not want to read.  Parts of the YANG learning curve
are so off the scale, that they will never be learned by some people.
These people will simply 'skip over' all the XPath cruft.

But what about the operators who know XPath?

You are raising a very legitimate argument.
I do not have enough implementation and operator experience
to know if the XPath mods in YANG are worth it.
The must-stmt may be more useful in theory than in practice.

Andy

---

From: Martin Bjorklund <[email-masked]>
Date: Mon, 04 Aug 2008 22:52:14 +0200 (CEST)

> like defining empty set to contain something. Null namespace means NO

Maybe we should reword our spec and say "Elements without a namespace
refer to nodes in the current module.".

> will never work (unmodified) in validation tools such as XSLT

I think you will have to set up your execution environment carefully
anyway if you want to use such tools. For example, you'll have to give
them the entire config data store as one instance document, and if you
have one instance document you will have one root, and that means that
your absolute XPath statements will not work w/o modification.

/martin

---

From: Martin Bjorklund <[email-masked]>
Date: Mon, 04 Aug 2008 23:02:01 +0200 (CEST)

> YANG XPath has 'extra features' right?

No.

>     o  One variable "this", which is the context node, is defined.

This is part of the XPath "context" (or execution environment) which
users of XPath must specify.

> YANG requires custom implementation of XPath already.

No!  YANG *does not* require an implementation at all - this is what
we currently say:

  Note that the XPath expression is conceptually evaluated.  This
  means that an implementation does not have to use an XPath evaluator
  on the device.  How the evaluation is done in practice is an
  implementation decision.

The idea is that the must expression tells the implementer about a
constraint, and I suspect that often this constraint will be enforced
by hand-written code, rather than automatically by the engine.

> the WG thought we were doing.

IMO we are using XPath 1.0.

/martin

---

From: Andy Bierman <[email-masked]>
Date: Mon, 04 Aug 2008 14:21:44 -0700

> users of XPath must specify.

What about the 'self' axis in sec 2.2 of the XPath 1.0 spec,
or the abbreviated syntax '.', for the context node?

Why does YANG need a new one?

>   on the device.  How the evaluation is done in practice is an

This is a fairly content-free definition.
As long as you fully support all of XPath 1.0, and
the YANG context, you do not have to use an XPath
interpreter.  I'm not sure what that means.

There are actually 2 YANG contexts -- the definition context will
include choice and/or case names (augment target), but not the
execution context (must, when targets), which allows the full
XPath syntax.  The limited syntax allowed in the unique-stmt is
really a subset of the definition context, so it doesn't count.

> by hand-written code, rather than automatically by the engine.

I agree -- for the agent -- but it is quite likely that an
application will try to use the must and when clauses
in an automated fashion.

Andy

---

From: Ladislav Lhotka <[email-masked]>
Date: Tue, 05 Aug 2008 10:46:47 +0200

> the WG thought we were doing.

If the draft said the must argument is a YumYum expression, it would be
natural to expect a precise definition of such expressions. This way, it
is left to the reader to figure out what this "XPath" expression really
means, what remained from XPath standard and what was modified. It is a
slippery surface.

Lada

-- 
Ladislav Lhotka, CESNET
PGP Key ID: E74E8C0C

---

From: Ladislav Lhotka <[email-masked]>
Date: Tue, 05 Aug 2008 11:12:19 +0200

> IMO we are using XPath 1.0.

Does it mean all XPath functions such as count() or contains(), and axes
such as preceding-sibling are supported? Can I just use dot (.) instead
of $this?

In any case, the handling of namespaces violates the XPath 1.0 standard.

Lada

-- 
Ladislav Lhotka, CESNET
PGP Key ID: E74E8C0C

---

From: Martin Bjorklund <[email-masked]>
Date: Tue, 05 Aug 2008 22:18:56 +0200 (CEST)

Hi,

Ladislav Lhotka <[email-masked]> wrote:
> This way, it
> means, what remained from XPath standard and what was modified.

I'm guessing that this statement refers to something else than which
nodes unprefixed elements refer to.  Could you be more specific?  What
text should we add to make sure there is no confusion about the fact
that we use unmodified xpath 1.0?

/martin

---

From: Martin Bjorklund <[email-masked]>
Date: Tue, 05 Aug 2008 22:28:43 +0200 (CEST)

> interpreter.  I'm not sure what that means.

It means that the must expression specifies the constraint, and you
are free to implement this constraint enforcement in any way you
want.

/martin

---

From: Ladislav Lhotka <[email-masked]>
Date: Tue, 05 Aug 2008 23:02:01 +0200

> that we use unmodified xpath 1.0?

With this I replied to Andy's claim that the must expression in fact
doesn't use XPath. As I said, I think the namespace handling is not in
accord with XPath 1.0 spec and also the '$this' variable is not in the
spec - in fact, it's IMO not needed, the 'self' axis (or '.') and the
current() function should do.

Lada

-- 
Ladislav Lhotka, CESNET
PGP Key ID: E74E8C0C

---

From: Martin Bjorklund <[email-masked]>
Date: Tue, 05 Aug 2008 23:11:32 +0200 (CEST)

Ladislav Lhotka <[email-masked]> wrote:
> spec

XPath 1.0 supports variables.  We define one variable called 'this'.

> - in fact, it's IMO not needed, the 'self' axis (or '.') and the

No, since '.' selects the current context node, but the context node
changes in the expression.

Compare
   
  leaf address {
    type keyref {
      path "../../interface[name = $this/../ifname]/address/ip";
   
with

  leaf address {
    type keyref {
      path "../../interface[name = ./../ifname]/address/ip";

$this refers to the 'address' node, but the '.' in the second
expression refers to the 'interface' node.

You can verify this by experimenting with some xpath expressions.

/martin

---

From: Ladislav Lhotka <[email-masked]>
Date: Wed, 06 Aug 2008 07:44:47 +0200

>       path "../../interface[name = $this/../ifname]/address/ip";

        path "../../interface[name = current()/../ifname]/address/ip";

Lada

-- 
Ladislav Lhotka, CESNET
PGP Key ID: E74E8C0C

---

From: Martin Bjorklund <[email-masked]>
Date: Wed, 06 Aug 2008 21:43:31 +0200 (CEST)

>         path "../../interface[name = current()/../ifname]/address/ip";

First of all, current() is not an XPath 1.0 core function.  I believe
is an XSLT addition.  Second, I found this
(http://developer.mozilla.org/en/docs/XPath:Functions:current)

  The current node is always the same as the context node. The
  following two are symantically equivalent.

    <xsl:value-of select="current()"/>

    <xsl:value-of select="."/>

So it doesn't help us.

/martin

---

From: Andy Bierman <[email-masked]>
Date: Wed, 06 Aug 2008 12:53:39 -0700

>     <xsl:value-of select="."/>

I think I agree with Martin that we are not changing XPath 1.0.
I should not have said that.  We are creating 2 new custom
contexts in which XPath expressions can be evaluated.
XPath 1.0 is not changed at all.

IMO, there is enough justification for '$this', just make sure
all the mailing list examples and definitions make it
into the draft.

Nothing helps an implementer more than a correct example.

Andy

---

From: Ladislav Lhotka <[email-masked]>
Date: Thu, 07 Aug 2008 09:16:25 +0200

> First of all, current() is not an XPath 1.0 core function.  I believe

Yes, you are right. However, in Schematron you can use this function,
too, and it is used quite often.

>     <xsl:value-of select="."/>

No, this is only true in the outermost level of the expressions. Section
12.4 of the XSLT spec (http://www.w3.org/TR/xslt#misc-func) makes it
very clear.

Lada

-- 
Ladislav Lhotka, CESNET
PGP Key ID: E74E8C0C

---

From: Phil Shafer <[email-masked]>
Date: Fri, 08 Aug 2008 15:45:32 -0400

>        path "../../interface[name = current()/../ifname]/address/ip";

You're absolutely right.  $this and current() are identical.  We
should mimic this XSLT function instead of rolling our own.

Thanks,
 Phil

---

From: Phil Shafer <[email-masked]>
Date: Fri, 08 Aug 2008 15:46:27 -0400

>refer to nodes in the current module.".

This sounds like a fine solution to me.

Thanks,
 Phil

---

From: Phil Shafer <[email-masked]>
Date: Fri, 08 Aug 2008 15:51:29 -0400

>actually adapt more to the language, than if you would do by keeping the

XPath expressions are always evaluated in a context which is defined
by the environment.  For example in XSLT, the binding of prefixes
to namespaces is defined by the nesting of the XSLT document.  The
context has the prefix binding if one of the parent elements contains
the xmlns attribute to bind it.  A developer writing an XSLT script
is aware of those rules.  The YANG scenario is identical.  We define
rules about how the context is built, the developer knows those
rules, and everyone is happy.

Thanks,
 Phil

---

From: Martin Bjorklund <[email-masked]>
Date: Sun, 10 Aug 2008 21:30:52 +0200 (CEST)

> should mimic this XSLT function instead of rolling our own.

Unless someone objects, I will make this change and use current()
instead of $this.

/martin

---

From: David Partain <[email-masked]>
Date: Thu, 21 Aug 2008 10:37:02 +0200

Hi,

That makes good sense to me...  (and no one else has objected)

David