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

[Andy Bierman]

On Fri, Jul 24, 2020 at 2:40 AM Juergen Schoenwaelder <
j.schoenwael...@jacobs-university.de> wrote:

> On Sat, Jul 18, 2020 at 09:00:42AM -0700, Andy Bierman wrote:
> > On Sat, Jul 18, 2020 at 8:42 AM Vladimir Vassilev <
> > vladi...@lightside-instruments.com> 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.
>
>

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


>
> --
> Juergen Schoenwaelder   Jacobs University Bremen gGmbH
> Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
> Fax:   +49 421 200 3103 
>
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

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

[Juergen Schoenwaelder]

On Sat, Jul 18, 2020 at 09:00:42AM -0700, Andy Bierman wrote:
> On Sat, Jul 18, 2020 at 8:42 AM Vladimir Vassilev <
> vladi...@lightside-instruments.com> 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: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103 

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

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

[Ladislav Lhotka]

Juergen Schoenwaelder  writes:

>   - 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.

XPath context is not only namespaces and prefixes. For example, are the extra 
functions from RFC 7950 permitted or not?

>
>   - This interacts with the definition of node-instance-identifier.

I think it is necessary to first redefine the lexical representation of 
instance-identifier in YANG.

>
>   - 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.

I vote for (i), as long as a general solution is probably impossible.

Lada

>
>   - Proposal: ?
>
> /js
>
> -- 
> Juergen Schoenwaelder   Jacobs University Bremen gGmbH
> Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
> Fax:   +49 421 200 3103 
>
> ___
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod

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

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

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

[Andy Bierman]

On Sat, Jul 18, 2020 at 8:42 AM Vladimir Vassilev <
vladi...@lightside-instruments.com> 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.


> > /js
> >
>

Andy


>
> ___
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
>
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

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

[Vladimir Vassilev]

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



___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

[netmod] rfc6991bis: yang:xpath1.0

[Juergen Schoenwaelder]

  - 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: ?

/js

-- 
Juergen Schoenwaelder   Jacobs University Bremen gGmbH
Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103 

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod