Re: [netmod] xpath expressions in JSON

[Martin Bjorklund <[e-mail]>]

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.


/martin


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