Andy Bierman <[email protected]> wrote: > On Thu, Oct 18, 2018 at 12:58 PM, Martin Bjorklund <[email protected]> wrote: > > > Andy Bierman <[email protected]> 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 < > > > [email protected]> 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 [email protected] > > > > > > > > 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 > > > >> [email protected] > > > >> https://www.ietf.org/mailman/listinfo/netmod > > > >> > > > > > > > > _______________________________________________ > > > > netmod mailing list > > > > [email protected] > > > > https://www.ietf.org/mailman/listinfo/netmod > > > > > > _______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
