Andy Bierman <a...@yumaworks.com> 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 <
> vladi...@transpacket.com> 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 ietf-netconf-monitor...@2010-10-04.yang
> >
> > 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
> >> netmod@ietf.org
> >> https://www.ietf.org/mailman/listinfo/netmod
> >>
> >
> > _______________________________________________
> > 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
