Subject: [netmod] identityref and XPath

From: Ladislav Lhotka <[email-masked]>
Date: Thu, 27 Aug 2009 09:55:20 +0200

Hi,

Sec. 9.10.5 shows how local XML prefixes are used for representing
values of "identityref" type. However, this won't work in XPath
expressions because XPath doesn't know this type and there is no way for
properly mapping the prefixes to URIs.

For example, assume "my-crypto" model in 9.10.5 contains another
top-level leaf

    leaf foo {
        when "../crypto = 'des:des3'";
        ....
    }

then the 'when' condition will be true for

    <crypto xmlns:des="http://example.com/des">des:des3</crypto>

but false for

    <crypto xmlns:x="http://example.com/des">x:des3</crypto>

even though the text says that both representations encode the same
leaf.

Possible solutions:

1. Use the module name for qualifying identity names, e.g.

    when "../crypto = 'des.des3'"

   and
    
    <crypto>des.des3</crypto>

   (note that the module name and prefix are the same in the example)

2. Use full URI, e.g.,

    when "../crypto = '{http://example.com/des}des3'"

   and

    <crypto>{http://example.com/des}des3</crypto>

3. Define an XPath extension function, e.g.

    when "yang:is-identity(../crypto, 'des:des3')";

   Here, the XML instance representation could remain (with local 
   prefixes).

In my view, #1 would be the best compromise for YANG 1.0 provided that
module names will be mostly unique.

If YANG used other XPath extension functions, #3 would be probably the
right solution.

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

---

From: Martin Bjorklund <[email-masked]>
Date: Thu, 27 Aug 2009 10:19:54 +0200 (CEST)

> If YANG used other XPath extension functions, #3 would be probably the

Actually, YANG does define another extension function - current().  I
sort of like the module.name syntax, but it is different from what we
have in other places, so my preference would be #3 followed by #1.

/martin

---

From: Ladislav Lhotka <[email-masked]>
Date: Thu, 27 Aug 2009 10:48:28 +0200

> Actually, YANG does define another extension function - current().  I

Well, current() isn't really new, it's an XSLT function and expressions
that use it will in most cases work out of the box - e.g. in XSLT and
Schematron.
 
> have in other places, so my preference would be #3 followed by #1.

I agree that #3 will be needed in the long term. For example, in the
recent PSAMP example,

    must "yang:byte-length() = ../payloadBytes";

might come handy.

The practical difficulty with this approach is that existing tools will
not understand these functions unless the extensions are implemented in
them.

Lada

-- 
Ladislav Lhotka, CESNET
PGP Key ID: E74E8C0C

---

From: Phil Shafer <[email-masked]>
Date: Thu, 27 Aug 2009 08:30:27 -0400

Any of these three would be fine, but I thought identifyref was
somehow imbued with the intelligence to handle prefixes in such a
way that the value "des:des3" is more than just a string, so changing
the prefix would be handled correctly.  #2 is probably the most
exact proposal, and #3 is the least, but all three are close enough
that none has a serious advantage.

Thanks,
 Phil

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

---

From: Andy Bierman <[email-masked]>
Date: Thu, 27 Aug 2009 06:11:28 -0700

> properly mapping the prefixes to URIs.

I see no reason to change this at all.
I found it easy to code -- no problems at all.

We cannot use des.des2 because we already decided
not to reserve any legal identifier characters
for delimiters.  (IMO, rather shortsighted, again).
(des.des2 is a legal YANG identifier.)

Andy

---

From: Ladislav Lhotka <[email-masked]>
Date: Thu, 27 Aug 2009 15:26:57 +0200

> I found it easy to code -- no problems at all.

For XPath 'des:des3' is just a plain string literal and '=' performs a
string equality test. Of course, if you as a developer look at the
condition, realize what it means and then implement it in your code,
it's easy, but not how XPath is supposed to work.

> (des.des2 is a legal YANG identifier.)

Right, dot mustn't be allowed in identifiers in this case.

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

---

From: Andy Bierman <[email-masked]>
Date: Thu, 27 Aug 2009 07:01:31 -0700

> it's easy, but not how XPath is supposed to work.

But I have to do that at least 10 times to implement XPath
for YANG, so what's one more?

You have to compare the value space, not the lexical space,
or YANG doesn't actually work. You have to hunt down des:des3
or even just des3, because you know the base of the identityref
from the YANG tpe.

Andy

---

From: Ladislav Lhotka <[email-masked]>
Date: Thu, 27 Aug 2009 16:13:45 +0200

> or even just des3, because you know the base of the identityref

Then it's YPath, not XPath. As long as YANG spec refers to XPath 1.0, it
must follow its semantics. Extension functions is a mechanism that is
supported by the (few) existing XPath processors I worked with, and made
official in XPath 2.0.

Lada

Lada

-- 
Ladislav Lhotka, CESNET
PGP Key ID: E74E8C0C

---

From: Martin Bjorklund <[email-masked]>
Date: Thu, 27 Aug 2009 16:20:26 +0200 (CEST)

Ladislav Lhotka <[email-masked]> wrote:
> must follow its semantics.

+1

> Extension functions is a mechanism that is

But also XPath 1.0 supports that we define our own functions.
current() might be implemented in most XPath libraries, but it is
still technically a function we have defined in YANG.  It is not part
of the core function library in XPath 1.0.

/martin

---

From: Andy Bierman <[email-masked]>
Date: Thu, 27 Aug 2009 07:28:21 -0700

Ladislav Lhotka wrote:
> Then it's YPath, not XPath. 

Oh, right. That's a bad thing.
Officially, we use XPath and support off-the-shelf XML tools.
I keep forgetting that.

So we need to invent some XPath-ish thing nobody else is using,
instead of a YANG-ish thing nobody else is using, even though
the 'foo = x:bar' syntax is the most user-friendly we will find?

YANG users who are not XPath experts
will not know the difference, or care, and XPath experts
will not know about the strange encoding in (2) or the new
function in (3).  They know about (foo=x:bar) though.

As long as YANG spec refers to XPath 1.0, it

Andy

---

From: Ladislav Lhotka <[email-masked]>
Date: Thu, 27 Aug 2009 16:51:00 +0200

> Officially, we use XPath and support off-the-shelf XML tools.

AFAIK, translating a YANG module to DSDL schemas is currently the only
way for validating an XML instance configuration against that module,
including the 'must' conditions etc. This is because off-the-shelf tools
are used.

> the 'foo = x:bar' syntax is the most user-friendly we will find?

Writing an extension for libxslt (for example) is much easier than
rewriting the guts.

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

---

From: Phil Shafer <[email-masked]>
Date: Thu, 27 Aug 2009 12:23:40 -0400

>supported by the (few) existing XPath processors I worked with, and made

This is way too narrow a line to draw.  XSLT uses XPath 1.0 and
manages to add new datatypes (RTF) and functions (even function-available())
without anyone trying to call it "XSLTPath".

Standards are meant to be reused, and this means adapting them to
their new environment.  Defining a "qname" type, with a type-specific
equality operator, does not mean we are severing our connection
with XPath.

Thanks,
 Phil

---

From: Martin Bjorklund <[email-masked]>
Date: Fri, 28 Aug 2009 10:03:21 +0200 (CEST)

> equality operator, does not mean we are severing our connection

Even if you are right, I think it would be a much bigger effort to
introduce a 'qname' type, than adding a new function.

(and I don't believe you are right - the XPath spec clearly allows you
to define new functions, but it does not say anything about new types)

/martin

---

From: Andy Bierman <[email-masked]>
Date: Fri, 28 Aug 2009 05:16:53 -0700

> to define new functions, but it does not say anything about new types)

I think a new function is the best way to go,
but Lada is correct that there are more types
than just identityref that embed XML prefixes into literals.

   - instance-identifier
   - identityref
   - xpath1.0 (ietf-yang-types)
   - qname (unsupported)

Andy

---

From: Martin Bjorklund <[email-masked]>
Date: Fri, 28 Aug 2009 14:55:43 +0200 (CEST)

> than just identityref that embed XML prefixes into literals.

It might make sense to be able to test these two types for equality,
so maybe we should add:

   is-identity(node, str)
   is-instance-identifier(node, str)

>    - xpath1.0 (ietf-yang-types)

Unless we have a mechanism for adding new XPath functions (hint, hint
;) then there will always be new types that cannot be compared
properly with standard XPath.  For this particular type, I don't think
it is a problem that it cannot be compared.

/martin

---

From: Phil Shafer <[email-masked]>
Date: Fri, 28 Aug 2009 10:07:37 -0400

>to define new functions, but it does not say anything about new types)

XSLT defined the new type:

http://www.w3.org/TR/xslt#section-Result-Tree-Fragments

    11.1 Result Tree Fragments

    Variables introduce an additional data-type into the expression
    language. This additional data type is called result tree
    fragment. A variable may be bound to a result tree fragment
    instead of one of the four basic XPath data-types (string,
    number, boolean, node-set). A result tree fragment represents
    a fragment of the result tree. A result tree fragment is treated
    equivalently to a node-set that contains just a single root
    node. However, the operations permitted on a result tree fragment
    are a subset of those permitted on a node-set. ....

I'm assuming that no one at w3c would contend that xslt is broken
in it's use of xpath.  I think this is a stable precedent that
we can safely follow with risk of heresy.

Thanks,
 Phil

---

From: Ladislav Lhotka <[email-masked]>
Date: Fri, 28 Aug 2009 17:15:53 +0200

> XSLT defined the new type:

Well, you can assign a result tree fragment (RTF) to a XSLT variable.
But if you want to use RTF in XPath expressions in a sensible way (i.e.
not as a string), you have to use an extension function - for instance,
exsl:node-set from EXSLT makes a nodeset out of RTF.

BTW, result tree fragments are gone in XPath 2.0.

But this is IMO not that important. We can of course extend and redefine
XPath 1.0 in any way, provided the definition is sound and complete.
This could serve well human readers of YANG modules that implement the
constraints directly in their code. However, from the viewpoint of
automated validation using off-the-shelf tools, there are three levels
of compatibility:

1. YANG XPath expressions are directly usable, or after a  
   transformation. This is what we have now and that's why the mapping 
   to Schematron works out of the box (except for instance-identifier 
   type, which also needs an extension function).

2. YANG XPath expressions use extension functions. Such extensions have 
   to be implemented in every XPath processor we want to use. This is 
   extra work but there is usually a well documented API.

3. Everything else requires substantial rewrite and the benefit of 
   an off-the-shelf tool is essentially lost.

Lada

-- 
Ladislav Lhotka, CESNET
PGP Key ID: E74E8C0C