Subject: [netmod] keys in instance-identifiers

From: Ladislav Lhotka <[email-masked]>
Date: Mon, 06 Jun 2016 10:13:47 +0200

Hi,

section 9.13 in rfc6020-bis says:

   The syntax for an instance-identifier is a subset of the XPath
   abbreviated syntax, formally defined by the rule
   "instance-identifier" in Section 14.

However, the ABNF only allows string literals in key predicates:

   key-predicate       = "[" *WSP key-predicate-expr *WSP "]"

   key-predicate-expr  = node-identifier *WSP "=" *WSP quoted-string

I think this leads to problems with keys that have a numeric
type. Consider this module:

module ii-key {
  yang-version 1.1;
  namespace "http://example.com/ii-key";
  prefix ik;

  list arr {
    key "k1";
    leaf k1 {
      type uint8;
    }
    leaf k2 {
      type string;
    }
  }
  leaf ii {
    type instance-identifier {
      require-instance true;
    }
  }
}

Now, is the following instance data valid?

<data xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"
	 xmlns:ik="http://example.com/ii-key">
  <ik:arr>
    <ik:k1>3</ik:k1>
    <ik:k2>foo</ik:k2>
  </ik:arr>
  <ik:ii>/ik:arr[ik:k1='03']/ik:k2</ik:ii>
</data>

DSDL validation says it isn't:

== Validating semantic constraints ...
--- Failed assert at "/nc:data/ik:ii":
    The instance "/nc:data/ik:arr[ik:k1='03']/ik:k2" must exist.

This is because XPath 1.0 spec mandates the *string* equality comparison
for the "k1" key, and '3' != '03'. If we used a number in the
key-predicate, then Schematron validation would succeed:

  <ik:ii>/ik:arr[ik:k1=03]/ik:k2</ik:ii>

This is however not a valid instance-identifier.

There are IMO two possible solutions to this issue:

1. Avoid reference to XPath, just use the ABNF for instance-indentifier
   syntax, and say that the equality comparison is performed on
   canonical values of keys and string literals in key-predicates.

2. Permit numeric literals in key-predicate and leaf-list-predicate.

Lada

-- 
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 6 Jun 2016 15:09:53 +0200

> 2. Permit numeric literals in key-predicate and leaf-list-predicate.

Section 7.6:

   A leaf node has a value, but no child nodes in the data tree.
   Conceptually, the value in the data tree is always in the canonical
   form (see Section 9.1).

Section 7.7:

   Conceptually, the values in the data tree are always in the canonical
   form (see Section 9.1).

Section 7.5.3:

   Note that since all leaf values in the data tree are conceptually
   stored in their canonical form (see Section 9.1), any XPath
   comparisons are done on the canonical value.

Do you suggest that there should be additional notes inserted at
various places? The general spirit I think has always been to use
canonical forms of the values.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>

---

From: Ladislav Lhotka <[email-masked]>
Date: Mon, 6 Jun 2016 15:43:23 +0200

> On 06 Jun 2016, at 15:09, Juergen Schoenwaelder <[email-masked]> wrote:
> 

For the leaf that's in the data tree – <ik:k1>3</ik:k1> – the canonical value is indeed used. And instance-identifier has no canonical value.

> canonical forms of the values.

We can assume that the data tree has all leaf values in their canonical form, but after that we must IMO exactly follow the XPath semantics because otherwise we could easily run into troubles. For example, sometimes the canonical form of comparison operands cannot be determined:

container top {
  must "foo + bar < '3'";
  leaf foo {
    type uint8;
  }
  leaf bar {
    type decimal64 {
      fraction-digits 2;
    }
  }
}

The canonical form of the sum foo + bar is undefined.

Lada

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 6 Jun 2016 16:02:06 +0200

> The canonical form of the sum foo + bar is undefined.

This example does not seem to relate to instance identifiers. I am not
sure what you are asking for. OLD NEW style of text proposals would
help me.

/js

---

From: Ladislav Lhotka <[email-masked]>
Date: Mon, 6 Jun 2016 16:21:44 +0200

> On 06 Jun 2016, at 16:02, Juergen Schoenwaelder <[email-masked]> wrote:
> 
> This example does not seem to relate to instance identifiers.

It doesn't, but you referred to generic rules for XPath usage in YANG. My point is that canonical form cannot be applied to literal values appearing in XPath expressions.

> I am not

This is for my option #2:

OLD

NEW

   key-predicate-expr  = node-identifier *WSP "=" *WSP ( quoted-string / decimal-value )

Lada

---

From: Martin Bjorklund <[email-masked]>
Date: Tue, 07 Jun 2016 14:45:43 +0200 (CEST)

Ladislav Lhotka <[email-masked]> wrote:
> 
> > On 06 Jun 2016, at 15:09, Juergen Schoenwaelder
> > <[email-masked]> wrote:
> > 
> For the leaf that's in the data tree – <ik:k1>3</ik:k1> – the
> canonical value is indeed used.

... which means that the i-i value must use "3", not "03".

> And instance-identifier has no
> canonical value.
> 
> > 
> We can assume that the data tree has all leaf values in their
> canonical form, but after that we must IMO exactly follow the XPath
> semantics because otherwise we could easily run into troubles. For
> example, sometimes the canonical form of comparison operands cannot be
> determined:
> 
> container top {
>   must "foo + bar < '3'";
>   leaf foo {
>     type uint8;
>   }
>   leaf bar {
>     type decimal64 {
>       fraction-digits 2;
>     }
>   }
> }
> 

I don't understand what this has to do with the i-i issue.

/martin

---

From: Martin Bjorklund <[email-masked]>
Date: Tue, 07 Jun 2016 14:47:04 +0200 (CEST)

>    key-predicate-expr  = node-identifier *WSP "=" *WSP ( quoted-string / decimal-value )

I don't think this is necessary.  When i-is are constructed, the
canonical value must be used.

/martin

---

From: Ladislav Lhotka <[email-masked]>
Date: Tue, 7 Jun 2016 16:03:43 +0200

> On 07 Jun 2016, at 14:47, Martin Bjorklund <[email-masked]> wrote:
> 

OK, this works for numbers, although it would IMO be more robust to utilise the ability of XPath to perform numeric comparisons.

But what if the canonical value isn't defined, e.g. when the list key is an identityref? It would be handy to be able to use the derived-from() function as a key predicate.

Lada

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 7 Jun 2016 16:14:37 +0200

> But what if the canonical value isn't defined, e.g. when the list key is an identityref? It would be handy to be able to use the derived-from() function as a key predicate.

Lada,

we are at a stage where the document should already be in the RFC
editor's hands. If you think you have found a _fatal flaw_, you have
to explain what the flaw is and you should ideally provide a clear
proposal how to fix the bug (OLD NEW style diff works best).
Essentially the same level of detail as expected for RFC errata.

/js