Re: [netmod] xpath expressions in JSON

[Martin Bjorklund <[e-mail]>]

Andy Bierman <[e-mail]> wrote:
> On Thu, Oct 18, 2018 at 12:58 PM, Martin Bjorklund <[e-mail]> wrote:
> 
> > Andy Bierman <[e-mail]> wrote:
> > > Hi,
> > >
> > > I strongly agree that a new data type is needed (ypath1.0 or just ypath
> > is
> > > fine)
> > > Adding new semantics or requirements to published data types is
> > > unacceptable.
> > >
> > > Also, we must get the type and module containing the data type right on
> > the
> > > first try.
> > > No moving it later because the import looks bad. That said, a "quick
> > > 6991-bis" is unrealistic,
> > > and a multi-year 6991-bis is unhelpful.
> > >
> > > Should there be a canonical format, based on module-names as prefixes?
> > > Consider how to compare 2 values using this data type.
> >
> > Ok.  So which alternative do you prefer for stream-xpath-filter, which
> > is supposed to work also for JSON?  The current definition doesn't
> > work for JSON.
> >
> >
> 
> I don't like calling it xpath when it is not XPath any more.

But stream-xpath-filter *is* XPath.  The alternative solutions differ
only in how the prefix mapping is defined.

> It should be as clear as possible to readers and designers that xpath
> means XPath and ypath is not XPath.
> 
> I would prefer a new encoding that allows the parent node module-name to be
> used somehow,
> consistent with the JSON encoding used now.
> 
> Perhaps each absolute-path expression starts with a module-name step and
> relative-path
> expressions assume the module name of the context node if there is no
> module-name.
> 
> Neither alternative below is a good long-term solution.

Agreed, but we need to find a solution for stream-xpath-filter, or
else we should remove it from SN.

> The old problems come up again:
> 
>   Client A writes the /foo node in XML.
>   Client B reads the /foo node returned in JSON
> 
> Which format is returned? Does the server magically convert the value for
> each encoding type?

Yes, just like it does with i-i and identityref.

> If we bother to fix this problem at all, then we should get rid of reliance
> on prefix to namespace mappings.

Long-term, yes!


/martin


> 
> 
> 
> 
> 
> > /martin
> >
> >
> 
> Andy
> 
> 
> >
> > >
> > >
> > > Andy
> > >
> > >
> > > On Thu, Oct 18, 2018 at 10:42 AM, Vladimir Vassilev <
> > > [e-mail]> wrote:
> > >
> > > > Hi,
> > > >
> > > > Seems this discussion affects 10 draft modules using the xpath1.0 type.
> > > > The proposed boilerplate description text that was not added to some
> > RFC
> > > > modules like [e-mail]
> > > >
> > > > should be as consistent as possible (or skipped based on the
> > > > ietf-netconf-monitoring precedent) until a better alternative is
> > available.
> > > > Here is an example of a better alternative.
> > > >
> > > >    typedef ypath1.0 {
> > > >     type xpath1.0;
> > > >     description
> > > >      "This type represents subset of XPATH 1.0 expressions
> > > >       that apply to a data tree conforming to a YANG model.
> > > >
> > > >       Each encoding should allow conversion to an encoding
> > > >       independent lexical representation where data node
> > > >       prefixes are resolved to and substituted with module
> > > >       names.
> > > >
> > > >       When a schema node is defined that uses this type, the
> > > >       description of the schema node MUST specify the
> > > >       context in which the expression is evaluated if it
> > > >       is different from the default context.
> > > >
> > > >       The default context is as follows:
> > > >
> > > >         o  The set of variable bindings is empty.
> > > >
> > > >         o  The function library is the core function library, and
> > > >            the XPath functions defined in section 10 in RFC 7950.
> > > >
> > > >         o  The context node is the leaf node.
> > > >
> > > >       ";
> > > >     reference
> > > >      "XPATH: XML Path Language (XPath) Version 1.0";
> > > >   }
> > > >
> > > > That said I do not object to short-term application of alternative A as
> > > > long as a long-term solution is on its way for future modules.
> > > >
> > > > Vladimir
> > > >
> > > > On 10/18/18 12:30 PM, Martin Bjorklund wrote:
> > > >
> > > >> Hi,
> > > >>
> > > >> Going back to the most urgent issue, what is this WG's recommendation
> > > >> for the subscribed-notifications draft in NETCONF wrt/ their usage of
> > > >> yang:xpath1.0 in filters?
> > > >>
> > > >> To summarize:
> > > >>
> > > >> We already have
> > > >>
> > > >>    o  instance-identifier in XML uses prefixes from the XML document
> > > >>    o  instance-identifier in JSON uses module names as prefixes
> > > >>    o  XPath in NETCONF filter uses prefixes from the XML document
> > > >>    o  XPath in JSON query filter uses module names as prefixes
> > > >>
> > > >>
> > > >> Alternative A:
> > > >> --------------
> > > >>
> > > >> Use different encodings for "stream-xpath-filter" as well, depending
> > > >> on if it is XML or JSON.
> > > >>
> > > >> We would do in SN:
> > > >>
> > > >>      o  If the node is encoded in XML, the set of namespace
> > > >>         declarations are those in scope on the
> > > >>         'stream-xpath-filter' leaf element.
> > > >>
> > > >>      o  If the node is encoded in JSON, the set of namespace
> > > >>         declarations is the set of prefix and namespace pairs
> > > >>         for all supported YANG modules, where the prefix is
> > > >>         the YANG module name and the namespace is as defined
> > > >>         by the "namespace" statement in the YANG module.
> > > >>
> > > >> Pro: the format is consistent within each encoding.
> > > >>
> > > >> Con: unclear how to handle other encodings.
> > > >> Con: we keep using context-depending encodings.
> > > >>
> > > >> We could probably add that CBOR uses the same representation as JSON.
> > > >>
> > > >> Example in XML:
> > > >>
> > > >>    <stream-xpath-filter
> > > >>        xmlns:if="urn:ietf:params:xml:ns:yang:ietf-interfaces"
> > > >>        xmlns:ip="urn:ietf:params:xml:ns:yang:ietf-ip">
> > > >>      /if:interfaces/if:interface/ip:ipv4
> > > >>    </stream-xpath-filter>
> > > >>
> > > >> Example in JSON:
> > > >>
> > > >>    "stream-xpath-filter":
> > > >>      "/ietf-interfaces:interfaces/ietf-interfaces:interface/
> > ietf-ip:ipv4"
> > > >>
> > > >>
> > > >>
> > > >> Alternative B:
> > > >> --------------
> > > >>
> > > >> Use a non-context depending encoding, with the module name as prefix.
> > > >>
> > > >> We would do in SN:
> > > >>
> > > >>      o  The set of namespace
> > > >>         declarations is the set of prefix and namespace pairs
> > > >>         for all supported YANG modules, where the prefix is
> > > >>         the YANG module name and the namespace is as defined
> > > >>         by the "namespace" statement in the YANG module.
> > > >>
> > > >> Pro: the format is independent from the protocol encoding
> > > >>
> > > >> Con: in XML, this leaf is treated differently from other XPath
> > > >>       expressions, such as get-config filter and nacm rules.
> > > >>
> > > >> Example in XML:
> > > >>
> > > >>    <stream-xpath-filter>
> > > >>      /ietf-interfaces:interfaces/ietf-interfaces:interface/
> > ietf-ip:ipv4
> > > >>    </stream-xpath-filter>
> > > >>
> > > >> Example in JSON:
> > > >>
> > > >>    "stream-xpath-filter":
> > > >>      "/ietf-interfaces:interfaces/ietf-interfaces:interface/
> > ietf-ip:ipv4"
> > > >>
> > > >>
> > > >> My proposal is A.  I think it is more important with consistency
> > > >> within each encoding than across encodings.
> > > >>
> > > >> (This said, I would like to have a context-independent encoding of all
> > > >> YANG types in the future.  But not now.)
> > > >>
> > > >>
> > > >>
> > > >>
> > > >> /martin
> > > >>
> > > >> _______________________________________________
> > > >> netmod mailing list
> > > >> [e-mail]
> > > >> https://www.ietf.org/mailman/listinfo/netmod
> > > >>
> > > >
> > > > _______________________________________________
> > > > netmod mailing list
> > > > [e-mail]
> > > > https://www.ietf.org/mailman/listinfo/netmod
> > > >
> >