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

[Juergen Schoenwaelder <[e-mail]>]

On Sat, Jul 18, 2020 at 09:00:42AM -0700, Andy Bierman wrote:
> On Sat, Jul 18, 2020 at 8:42 AM Vladimir Vassilev <
> [e-mail]> wrote:
> 
> > 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.
> >
> >
> 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.
>

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: [phone]         Campus Ring 1 | 28759 Bremen | Germany
Fax:   [phone]         <https://www.jacobs-university.de/>