Subject: [netmod] [Technical Errata Reported] RFC7950 (5157)

From: RFC Errata System <[email-masked]>
Date: Mon, 16 Oct 2017 12:04:31 -0700 (PDT)

The following errata report has been submitted for RFC7950,
"The YANG 1.1 Data Modeling Language".

--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/errata/eid5157

--------------------------------------
Type: Technical
Reported by: Andy Bierman <[email-masked]>

Section: 14

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

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

Notes
-----
An instance identifier is forced to specify every key value to be a string
even though the YANG key leaf type could be a numeric type.
XPath does not require a quoted string here, just YANG.

Old:  /top/list[idx="4"]
New: /top/list[idx=4]

Instructions:
-------------
This erratum is currently posted as "Reported". If necessary, please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party  
can log in to change the status and edit the report, if necessary. 

--------------------------------------
RFC7950 (draft-ietf-netmod-rfc6020bis-14)
--------------------------------------
Title               : The YANG 1.1 Data Modeling Language
Publication Date    : August 2016
Author(s)           : M. Bjorklund, Ed.
Category            : PROPOSED STANDARD
Source              : NETCONF Data Modeling Language
Area                : Operations and Management
Stream              : IETF
Verifying Party     : IESG

---

From: Benoit Claise <[email-masked]>
Date: Sat, 21 Oct 2017 09:28:56 +0200

Dear all,

Shall I validate this one?

Regards, Benoit
> .

---

From: Andy Bierman <[email-masked]>
Date: Sat, 21 Oct 2017 11:16:40 -0700

> Shall I validate this one?

To add more context, this relates to the the RESTCONF JSON vs. XML
discussions in the NETCONF WG.

  leaf broken {
      type union {
        type int32;
        type string;
     }
  }

If all values of key leaf "broken" are sent as strings in an
instance-identifier,
then the int32 value may not match in all implementations, instead of the
string.
Allowing numbers as literals in addition to quoted strings allows the sender
to be specific, and all implementations to be consistent.

> Regards, Benoit

Andy

---

From: Vladimir Vassilev <[email-masked]>
Date: Sun, 22 Oct 2017 02:25:27 +0200

Hello,

I would like to use the occasion of this Errata report to point out some 
additional issues with the instance-identifier type definition.

IMO the instance-identifier built-in type has 2 additional problems that 
can be addressed with alternative and significantly more radical errata 
or fixed in a new version of YANG.:

Problem 1: The obvious limitation inherited from Xpath 1.0 - inability 
to escape single or double quote characters. In Xpath world this 
limitation is worked around by use of concat() which is not available in 
the YANG 1.1 instance-identifier definition. 2 examples of this limitation:

1. It is impossible to create value of type instance-identifier 
referencing nodes in lists with key string values containing both a 
single and a double quote characters e.g. ...<interface><name>"It's 
valid string!"</name></interface>.

2. Another example of the same problem would be a leaf of type 
instance-identifier referencing another leaf of type 
instance-identifier. With 2 references it works provided one is encoded 
with single quotes and the other with double but it is impossible to 
create third e.g.

YANG:

     list id-list {
       key "id";

       leaf id {
           type instance-identifier;
       }
     }

Data:

* /top/id-list[id="/top/list[idx='4']"]

* /top/id-list[id="/top/id-list[idx='/top/list[idx=4]'"] <assuming the 
proposed errata is also in effect>

* <next reference not possible with YANG 1.1>

Problem 2: The instance-identifier type lacks canonical form (which 
makes it the only data type with implementation dependent representation 
at the data level ... think of the integer types allowing optional 
spaces between the digits). This is in fact the only built-in data type 
that allows the server implementation to change the configuration data 
replacing double quotes with single or the other way around. Inserting 
white spaces where you did not have them when the configuration was 
submitted. You can not simply read a configuration and use fast data 
comparison without schema support just because of this type. This is 
useless flexibility for simple data type.

And this can be fixed if:

1. white spaces in instance-identifiers are prohibited

2. list key predicates are required in alphabetical order

3. strict quotation convention with escape option is added. (only 3. 
contradicts the sec. 9.13 ".. instance-identifier is a subset of the 
XPath ..")

Vladimir

On 10/21/2017 08:16 PM, Andy Bierman wrote:
>
>
> On Sat, Oct 21, 2017 at 12:28 AM, Benoit Claise <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     Dear all,
>
> then the int32 value may not match in all implementations, instead of 
> the string.
>         <http://www.rfc-editor.org/errata/eid5157>
>
>         Reported by: Andy Bierman <[email-masked]
>         <mailto:[email-masked]>>
>
>         Section: 14
>
>         Original Text
>         -------------
>         quoted-string
> _______________________________________________
> netmod mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netmod

---

From: Martin Bjorklund <[email-masked]>
Date: Mon, 23 Oct 2017 10:35:13 +0200 (CEST)

> Shall I validate this one?

No I don't think this is correct.  We choose a quoted string to be
able to correctly represent all YANG integer and decimal64 values.
Note that XPath doesn't have integers, just 64-bit floats.  This means
that not all 64-bit integers can be expressed as numbers in XPath.

/martin

---

From: Martin Bjorklund <[email-masked]>
Date: Mon, 23 Oct 2017 13:35:59 +0200 (CEST)

Vladimir Vassilev <[email-masked]> wrote:
> Hello,
> 
> I would like to use the occasion of this Errata report to point out
> some additional issues with the instance-identifier type definition.
> 
> IMO the instance-identifier built-in type has 2 additional problems
> that can be addressed with alternative and significantly more radical
> errata or fixed in a new version of YANG.:
> 
> limitation is worked around by use of concat() which is not available
> in the YANG 1.1 instance-identifier definition. 2 examples of this
> limitation:
> 
> instance-identifier. With 2 references it works provided one is
> encoded with single quotes and the other with double but it is
> impossible to create third e.g.
> 
> YANG:
> 
>     list id-list {
>       key "id";
> 
>       leaf id {
> * proposed errata is also in effect>
> 
> makes it the only data type with implementation dependent
> representation at the data level ... think of the integer types
> allowing optional spaces between the digits). This is in fact the only
> built-in data type that allows the server implementation to change the
> configuration data replacing double quotes with single or the other
> way around. Inserting white spaces where you did not have them when
> the configuration was submitted. You can not simply read a
> configuration and use fast data comparison without schema support just
> because of this type. This is useless flexibility for simple data
> type.
> 

Or perhaps use the order the keys are defined in the data model (the
"keys" statement").

> 3. strict quotation convention with escape option is added. (only
> 3. contradicts the sec. 9.13 ".. instance-identifier is a subset of
> the XPath ..")

I would like to change one more thing - I think it is unfortunate that
the lexical representation depends on the lexical context;
specifically that prefixes declared in the XML instance document is
used.  This applies also to identityref.  YANG 2.0 should use the same
encoding as JSON does for these datatypes.

/martin

---

From: Vladimir Vassilev <[email-masked]>
Date: Mon, 23 Oct 2017 13:57:53 +0200

> Or perhaps use the order the keys are defined in the data model (the
This is an option but then the e.g. xpath2instid() function 
implementations will need schema support.

Vladimir

---

From: Ladislav Lhotka <[email-masked]>
Date: Mon, 23 Oct 2017 14:57:25 +0200

> that not all 64-bit integers can be expressed as numbers in XPath.

I agree this would be a change in the spec, not an erratum. On the other hand,
it would be possible to use the JSON representation of scalar values as defined
in RFC 7951, which addresses the problems with 64-bit numbers.

Lada

-- 
Ladislav Lhotka
Head, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67

---

From: Andy Bierman <[email-masked]>
Date: Mon, 23 Oct 2017 07:26:33 -0700

> that not all 64-bit integers can be expressed as numbers in XPath.
It's OK to leave this out since it requires a code change.

Read sec. 2.3 again:

The node test text() is true for any text node.

Andy

---

From: Martin Bjorklund <[email-masked]>
Date: Mon, 23 Oct 2017 16:30:39 +0200 (CEST)

> It's OK to leave this out since it requires a code change.

Wrong thread?

> The node test text() is true for any text node.

Sure, but a node test is not a predicate!

/martin

---

From: Andy Bierman <[email-masked]>
Date: Mon, 23 Oct 2017 08:21:58 -0700

> > It's OK to leave this out since it requires a code change.

No -- customers who know XPath report this YANG-ism as a bug.
It would require 2 lines of code to be changed in our code to accept
numbers.
I don't think an errata should require a code change.

> Sure, but a node test is not a predicate!

But it returns true/false, not a node-set.
The expression /foo[text() = 'fred'] is not the same as /foo[. = 'fred']

Andy

---

From: Andy Bierman <[email-masked]>
Date: Mon, 23 Oct 2017 10:41:48 -0700

Hi,

To be clear, I am withdrawing this errata because existing implementations
may not accept a numeric literal in an instance-identifier.
I think this should be addressed in YANG 2.0 and this thread should be
recorded in the yang-next issue trac ker.

Andy

---

From: Kent Watsen <[email-masked]>
Date: Mon, 23 Oct 2017 17:52:00 +0000

Added.  https://github.com/netmod-wg/yang-next/issues/30

K.

On 10/23/17, 1:41 PM, "Andy Bierman" <[email-masked]<mailto:[email-masked]>> wrote:

Hi,

Andy

On Mon, Oct 23, 2017 at 7:30 AM, Martin Bjorklund <[email-masked]<mailto:[email-masked]>> wrote:
Andy Bierman <[email-masked]<mailto:[email-masked]>> wrote:
> On Mon, Oct 23, 2017 at 1:35 AM, Martin Bjorklund <[email-masked]<mailto:[email-masked]>> wrote:
>
> > Benoit Claise <[email-masked]<mailto:[email-masked]>> wrote:
> > > Dear all,
> > >

Wrong thread?

/martin

> > > > http://www.rfc-editor.org/errata/eid5157<https://urldefense.proofpoint.com/v2/url?u=http-3A__www.rfc-2Deditor.org_errata_eid5157&d=DwMFaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m=iqphTMkp51dLrCM-UzlrEywuJe9XtROxO8pnSRN0A7A&s=uwZM3AV1UAHdT57ba-bWCNGRcGtQ-1758c4l9ttQRUM&e=>
> > > >
> > > > Reported by: Andy Bierman <[email-masked]<mailto:[email-masked]>>
> > > >
> > > > Section: 14
> > > >
> > > > Original Text
> > > > -------------

---

From: Andy Bierman <[email-masked]>
Date: Mon, 23 Oct 2017 18:42:48 -0700

On Mon, Oct 23, 2017 at 4:57 AM, Vladimir Vassilev <[email-masked]
> wrote:

>>>            type instance-identifier;

Although the instance-identifier is problematic, it is rarely used at all,
let alone using it as a list key.

The XPath mixed-quotes problem is well-known, and the suggested
solution seems to be use the "concat" function

   /foo/bar[name=concat("It's a", ' "valid" string')]

Not very user friendly, is it?

> implementations will need schema support.

All the YANG tools I have seen generate the predicates in YANG key order.
The issue of canonical instance-identifier has been discussed many times,
and it is not possible to require the usage of specific prefixes in XML.
(Note that Lada fixed this for JSON in RFC 7951)

Only the string + expanded names can be properly compared in XML, not the
literal string
representing the XPath expression.

Vladimir

Andy

---

From: Robert Wilton <[email-masked]>
Date: Tue, 24 Oct 2017 10:03:03 +0100

On 24/10/2017 02:42, Andy Bierman wrote:
>
>
> On Mon, Oct 23, 2017 at 4:57 AM, Vladimir Vassilev 
> <[email-masked] <mailto:[email-masked]>> wrote:
>
>         Vladimir Vassilev <[email-masked]
>         <mailto:[email-masked]>> wrote:
>
>             Hello,
>

I suspect that this is unlikely to be popular, but I think that it would 
be nice if there was a plan to move away from XPath, and define a YANG 
specific equivalent instead.  Broadly it could follow the same format as 
XPath but be defined against a YANG data tree, and bind to YANG's 
types.  We could get rid of the bits of XPath that aren't really helpful 
or meaningful for YANG, and add in some new functionality/fixes that are 
helpful to solve the YANG specific problems related to path expressions.

Rob

---

From: Jan Lindblad <[email-masked]>
Date: Tue, 24 Oct 2017 12:41:16 +0200

Rob,

> I suspect that this is unlikely to be popular, but I think that it would be nice if there was a plan to move away from XPath, and define a YANG specific equivalent instead.  Broadly it could follow the same format as XPath but be defined against a YANG data tree, and bind to YANG's types.  We could get rid of the bits of XPath that aren't really helpful or meaningful for YANG, and add in some new functionality/fixes that are helpful to solve the YANG specific problems related to path expressions.

The idea has some merit, and I understand the background for this sentiment. Trying not to be on either side at this point, I would just like to point out that this would mean a considerable amount of work. Both for the WG to define this language, and later, for implementors to implement it.

/jan

---

From: Ladislav Lhotka <[email-masked]>
Date: Tue, 24 Oct 2017 12:57:57 +0200

> The idea has some merit, and I understand the background for this sentiment. Trying not to be on either side at this point, I would just like to point out that this would mean a considerable amount…

I agree, it is not a low-hanging fruit, and IETF isn't the right place to
develop such things.

It is actually a shame that so many clever technologies are sort of wasted
because they are tightly connected to XML (instead of being applicable to
general tree-like data).

It is perhaps also worth noting that XPath 1.0 spec now includes a note that
basically declares it deprecated and unmaintained.

Lada

---

From: Robert Wilton <[email-masked]>
Date: Tue, 24 Oct 2017 12:09:56 +0100

Hi Jan,

> The idea has some merit, and I understand the background for this sentiment. Trying not to be on either side at this point, I would just like to point out that this would mean a considerable amount…
Yes, definitely agree to both of these.

To ease implementation, then possibly a mapping (ideally supported with 
an open source conversion tool) could be defined between XPath and a new 
YANG path language.  How successfully this would be depends on how much 
a YANG path language differs/evolves beyond XPath.

One example of this was the NETMOD discussion [Retrieving Information 
Pointed by leafref].  It is possible to come up with an XPath expression 
that returns the required entries, but it required union operators at 
the top level of the expression, which is probably harder to implement 
efficiently (i.e. it is fine if you can determine that the two branches 
don't return overlapping entries, otherwise you have to collate and 
remove duplicates before returning them).  If it was possible to move 
the union operator further down the expression path then that might more 
closely map to an efficient implementation.

E.g. something more like this:

   /te/tunnels/(tunnel[name='foo'] | 
tunnel[name=/te/tunnels/tunnel[name='foo']/supporting-tunnels/supporting-tunnel/name]) 

Instead of this:

   /te/tunnels/tunnel[name='foo'] |
/te/tunnels/tunnel[name=/te/tunnels/tunnel[name='foo']/supporting-tunnels/supporting-tunnel/name]

Thanks,
Rob

---

From: Vladimir Vassilev <[email-masked]>
Date: Tue, 24 Oct 2017 14:27:13 +0200

> let alone using it as a list key.
It is used as a key in ietf-alarms /alarms/alarm-list/alarm.
>    /foo/bar[name=concat("It's a", ' "valiid" string')]
>
I think people naming their interfaces "It's a valid string!" can take 
it. Prettier escaping solutions are available e.g. C string but it will 
require more work then a line in the next YANG version RFC. IMO solution 
is needed either concat or an alternative one.

Practical reason: YANG 1.1 can not create instance-identifier to the 
alarm /alarms/alarm-list/alarm[... 
resource="/interfaces/interface[name='eth0']"]. And this is not the 
"That's a valid string!" named interface. The "That's a valid string!" 
interface alarms can not be reported as a valid ietf-alarms 
instance-identifier based resource alarm at all.

> All the YANG tools I have seen generate the predicates in YANG key order.
Yes.

If Xpath came with a canonical form definition (prohibiting spaces, 
redundant duplication of namespace prefixes in children, order of 
predicates, canonical quotation rule, and some flexibility as of the 
node prefix semantics) we would not need to have this discussion. Seems 
no other modeling language of hierarchical data has reusable 
instance-identifier datatype with the necessary properties and I can see 
this as something that can go in separate RFC specifying generic data 
type making canonic definition from Xpath that YANG can reuse. In that 
case the alphabetic order makes sense moving some constraints into the 
generic definition of the type one can validate without the context 
schema but it is not of significant importance.

> (Note that Lada fixed this for JSON in RFC 7951)
Yes.
>
> Only the string + expanded names can be properly compared in XML, not 
> the literal string
Yes.

I do not see the need of major rework just making the Xpath subset rules 
stricter with canonical requirement and either allowing concat() (also 
with canonic rule producing predictable result e.g. to be used only for 
escaping single quotes and prohibiting double quotes in predicates 
otherwise). Even with RFC7951 prefix rules added in the 
instance-identifier can still be a valid Xpath subset requiring trivial 
prefix replacements so that it can be used with non-YANG aware XML tools 
keeping that option open.

Vladimir
>                 On Sat, Oct 21, 2017 at 12:28 AM, Benoit Claise
>                 <[email-masked] <mailto:[email-masked]>
>                 <mailto:[email-masked] <mailto:[email-masked]>>>
>                 wrote:
>
>                      Dear all,
>
>                 Allowing numbers as literals in addition to quoted
>                 strings allows the
>                 sender
>                          <http://www.rfc-editor.org/errata/eid5157
>                 <http://www.rfc-editor.org/errata/eid5157>>
>
>                 <mailto:[email-masked]>
>                          <mailto:[email-masked]
>                 <mailto:[email-masked]>>>
>
>                          Section: 14
>
>                          Original Text
>                          -------------
>                          An instance identifier is forced to specify
>                 every key value to
>                          be a string
>                          This erratum is currently posted as
>                 "Reported". If necessary,
>                          please
>                 [email-masked] <mailto:[email-masked]>
>                 <https://www.ietf.org/mailman/listinfo/netmod>
>
>             [email-masked] <mailto:[email-masked]>
>             <https://www.ietf.org/mailman/listinfo/netmod>
>
>
>

---

From: Andy Bierman <[email-masked]>
Date: Tue, 24 Oct 2017 10:06:51 -0700

On Tue, Oct 24, 2017 at 5:27 AM, Vladimir Vassilev <[email-masked]

>> On Mon, Oct 23, 2017 at 4:57 AM, Vladimir Vassilev <
>> [email-masked] <mailto:[email-masked]>> wrote:
>>
> I think people naming their interfaces "It's a valid string!" can take it.
> Prettier escaping solutions are available e.g. C string but it will require
> more work then a line in the next YANG version RFC. IMO solution is needed
> either concat or an alternative one.
>
> Practical reason: YANG 1.1 can not create instance-identifier to the alarm
> /alarms/alarm-list/alarm[... resource="/interfaces/interface[name='eth0']"].
> And this is not the "That's a valid string!" named interface. The "That's a
> valid string!" interface alarms can not be reported as a valid ietf-alarms

Actually the XPath designers made a reasonable trade-off by using concat as
the solution to
a problem that rarely happens.   It is up to the IETF to define YANG in a
way that does
not ignore the XPath solutions.

Andy

> predicates, canonical quotation rule, and some flexibility as of the node
> prefix semantics) we would not need to have this discussion. Seems no other
> modeling language of hierarchical data has reusable instance-identifier
> datatype with the necessary properties and I can see this as something that
> can go in separate RFC specifying generic data type making canonic
> definition from Xpath that YANG can reuse. In that case the alphabetic
> order makes sense moving some constraints into the generic definition of
> the type one can validate without the context schema but it is not of
> significant importance.
>
> stricter with canonical requirement and either allowing concat() (also with
> canonic rule producing predictable result e.g. to be used only for escaping
> single quotes and prohibiting double quotes in predicates otherwise). Even
> with RFC7951 prefix rules added in the instance-identifier can still be a
> valid Xpath subset requiring trivial prefix replacements so that it can be
> used with non-YANG aware XML tools keeping that option open.
>
> Vladimir
>
>>
>>
>>     Vladimir
>>
>>
>>
>> Andy
>>
>>

---

From: Vladimir Vassilev <[email-masked]>
Date: Wed, 25 Oct 2017 08:47:15 +0200

On 10/24/2017 07:06 PM, Andy Bierman wrote:

>
>
> On Tue, Oct 24, 2017 at 5:27 AM, Vladimir Vassilev 
>         <[email-masked] <mailto:[email-masked]>
>         <mailto:[email-masked]
>         <mailto:[email-masked]>>> wrote:
>
>         <mailto:[email-masked]>
>                 <mailto:[email-masked]
>         <mailto:[email-masked]>>> wrote:
>
>                     Hello,
>
>                     I would like to use the occasion of this Errata
>         report to
>                     point out
>                     some additional issues with the
>         instance-identifier type
>                     definition.
>
>                     IMO the instance-identifier built-in type has 2
>         additional
>                     problems
>                     that can be addressed with alternative and
>         significantly
>                     more radical
>                     Problem 1: The obvious limitation inherited from
>         Xpath 1.0
>                     - inability
>                     limitation is worked around by use of concat()
>         which is
>                     not available
>                     in the YANG 1.1 instance-identifier definition. 2
>         examples
>                     of this
>                     limitation:
>
>                     instance-identifier. With 2 references it works
>         provided
>                     one is
>     I think people naming their interfaces "It's a valid string!" can
>     take it. Prettier escaping solutions are available e.g. C string
>     but it will require more work then a line in the next YANG version
>     RFC. IMO solution is needed either concat or an alternative one.
>
>     Practical reason: YANG 1.1 can not create instance-identifier to
>     the alarm /alarms/alarm-list/alarm[...
>     resource="/interfaces/interface[name='eth0']"]. And this is not
>     the "That's a valid string!" named interface. The "That's a valid
>     string!" interface alarms can not be reported as a valid
>     ietf-alarms instance-identifier based resource alarm at all.
>
>
>
>
> Actually the XPath designers made a reasonable trade-off by using 
> concat as the solution to
> a problem that rarely happens.   It is up to the IETF to define YANG 
> in a way that does
Yes. How about some proper rules mandating th use of quotes and concat 
like: 1. Only allow use of double quotes when there is single quote 
present. 2. Only use concat when there is both single and double quotes 
present to split the string into 1 char single quote strings and the rest.

Then  /foo/bar[name=concat('It',"'",'s a valid string!"')] is the only 
possible canonic representation for all implementations and the solution 
is solving the rare problem without reinventing the wheel.

Vladimir
>                     *
>         /top/id-list[id="/top/id-list[idx='/top/list[idx=4]'"]
>                     <assuming the
>                     Problem 2: The instance-identifier type lacks
>         canonical
>                     form (which
>                     representation at the data level ... think of the
>         integer
>                     types
>                     allowing optional spaces between the digits). This
>         is in
>                     fact the only
>                     built-in data type that allows the server
>         implementation
>                     to change the
>                     configuration data replacing double quotes with
>         single or
>                     the other
>                     way around. Inserting white spaces where you did
>         not have
>                     them when
>                     configuration and use fast data comparison without
>         schema
>                     support just
>     If Xpath came with a canonical form definition (prohibiting
>     spaces, redundant duplication of namespace prefixes in children,
>     order of predicates, canonical quotation rule, and some
>     flexibility as of the node prefix semantics) we would not need to
>     have this discussion. Seems no other modeling language of
>     hierarchical data has reusable instance-identifier datatype with
>     the necessary properties and I can see this as something that can
>     go in separate RFC specifying generic data type making canonic
>     definition from Xpath that YANG can reuse. In that case the
>     alphabetic order makes sense moving some constraints into the
>     generic definition of the type one can validate without the
>     context schema but it is not of significant importance.
>
>         Only the string + expanded names can be properly compared in
>         XML, not the literal string
>     I do not see the need of major rework just making the Xpath subset
>     rules stricter with canonical requirement and either allowing
>     concat() (also with canonic rule producing predictable result e.g.
>     to be used only for escaping single quotes and prohibiting double
>     quotes in predicates otherwise). Even with RFC7951 prefix rules
>     added in the instance-identifier can still be a valid Xpath subset
>     requiring trivial prefix replacements so that it can be used with
>     non-YANG aware XML tools keeping that option open.
>
>     Vladimir
>
>
>
>             Vladimir
>
>
>
>         Andy
>
>
>                     3. contradicts the sec. 9.13 "..
>         instance-identifier is a
>                     subset of
>                     the XPath ..")
>
>                 used.  This applies also to identityref.  YANG 2.0
>         should use
>                 the same
>         <mailto:[email-masked] <mailto:[email-masked]>>
>                         <mailto:[email-masked]
>         <mailto:[email-masked]> <mailto:[email-masked]
>         <mailto:[email-masked]>>>>
>                         wrote:
>
>                              Dear all,
>
>                         To add more context, this relates to the the
>         RESTCONF
>                         JSON vs. XML
>                         If all values of key leaf "broken" are sent as
>         strings
>                         in an
>                         instance-identifier,
>         <http://www.rfc-editor.org/errata/eid5157>>>
>
>                                  Reported by: Andy Bierman
>         <[email-masked] <mailto:[email-masked]>
>         <mailto:[email-masked]>>>>
>
>                                  Section: 14
>
>                                  Original Text
>                                  -------------
>                                     key-predicate-expr  =
>         node-identifier *WSP
>                         "=" *WSP
>                                  quoted-string
>
>                                  Corrected Text
>                                  --------------
>                                     key-predicate-expr  =
>         node-identifier *WSP
>                         "=" *WSP
>                                  even though the YANG key leaf type
>         could be a
>                         numeric type.
>                                  XPath does not require a quoted
>         string here,
>                         just YANG.
>
>                                  Old:  /top/list[idx="4"]
>                                  New: /top/list[idx=4]
>
>                                  Instructions:
>                                  -------------
>                                  use "Reply All" to discuss whether it
>         should
>                         be verified or
>                                  can log in to change the status and
>         edit the
>                         report, if necessary.
>
>                                  Source              : NETCONF Data
>         Modeling
>                         Language
>         <mailto:[email-masked] <mailto:[email-masked]>>
>                         <https://www.ietf.org/mailman/listinfo/netmod
>         <https://www.ietf.org/mailman/listinfo/netmod>>
>
>         <mailto:[email-masked] <mailto:[email-masked]>>
>                     <https://www.ietf.org/mailman/listinfo/netmod
>         <https://www.ietf.org/mailman/listinfo/netmod>>
>
>
>
>
>

---

From: Andy Bierman <[email-masked]>
Date: Thu, 26 Oct 2017 09:02:14 -0700

> ....
>> ...
I guess if you wanted to create the most complex module possible,
using an XPath instance-identifier as a list key is a good start.

It's too bad we can't use the RESTCONF path URI string as an i-i:

  - the only representation is also the canonical representation
  - the list keys are much less verbose (required to be in schema order)
  - percent-encoded chars are allowed, which are simpler than character
entities
    and much simpler than the concat() function
  - no use of prefix mappings at all so i-i strings are complete and
permanent

Andy

---

From: Ladislav Lhotka <[email-masked]>
Date: Thu, 26 Oct 2017 19:55:58 +0200

On Thu, 2017-10-26 at 09:02 -0700, Andy Bierman wrote:
> 
> 
> On Tue, Oct 24, 2017 at 5:27 AM, Vladimir Vassilev <[email-masked]> wrote:

Why not? Just use JSON. XML is bound to be abadoned, sooner or later.

Lada

>   - percent-encoded chars are allowed, which are simpler than character entities
>   - no use of prefix mappings at all so i-i strings are complete and permanent
> 
> 
> Andy
> 
> 
>  
>