Subject: Re: [netmod] rfc6991bis: yang:xpath1.0

From: Vladimir Vassilev <[email-masked]>
Date: Sat, 18 Jul 2020 17:41:48 +0200

On 17/07/2020 21.14, Juergen Schoenwaelder wrote:

> - How do we deal with xpath expressions in other encodings
> such as JSON. Do we assume an xpath context populated with
> module names such that module names can be used to qualify
> path expressions. This may need discussion and/or a new
> definition.
>
> - This interacts with the definition of node-instance-identifier.
>
> - Options: (i) Leave this definition as it is. (ii) Detail how this
> type work with encodings that use module names instead of prefixes
> to qualify names.
>
> - Proposal: ?

How about leaving the xpath1.0 type definition as it is and specifying a 
canonical form for the node-instance-identifier where namespace prefixes 
must be module names.

> /js

---

From: Andy Bierman <[email-masked]>
Date: Sat, 18 Jul 2020 09:00:42 -0700

> canonical form for the node-instance-identifier where namespace prefixes
Since (i) is the only BC option why is (ii) even being considered?
Of course a new type name is needed to change the XPath syntax
to something that is not backward-compatible.

> > /js

Andy

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

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 24 Jul 2020 11:40:23 +0200

> to something that is not backward-compatible.

The idea was not to propose something non-backwards compatible but to
try to explain how xpath1.0 values work with non-XML encodings. But
perhaps this is 'unexplainable' in the sense that people deal with
this in different ways.

/js

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

---

From: Andy Bierman <[email-masked]>
Date: Fri, 24 Jul 2020 09:37:45 -0700

> perhaps this is 'unexplainable' in the sense that people deal with

IMO it is better to use a new type definition where the prefixes MUST be
module names
rather than overload a widely deployed type definition with semantics that
the prefixes
MAY be module names.

I prefer a new node-instance-identifier typedef, based on RFC 8040 sec.
3.5.3,
but that is another discussion.

/js

Andy