On Thu, Oct 18, 2018 at 1:32 PM, Martin Bjorklund <m...@tail-f.com> wrote:
> Andy Bierman <a...@yumaworks.com> wrote:
> > On Thu, Oct 18, 2018 at 12:58 PM, Martin Bjorklund <m...@tail-f.com>
> wrote:
> >
> > > 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.
> > >
> > >
> >
> > 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.
>
I don't think it should be called XPath if module-names are used as
prefixes.
Alternative A using a special data type is the least objectionable I guess
Andy
> > 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 <
> > > > 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
