On Thu, Oct 11, 2018 at 9:16 AM, Martin Bjorklund <m...@tail-f.com> wrote:
> Robert Wilton <rwil...@cisco.com> wrote: > > Hi Reshad, > > > > Please see RW: inline. > > > > > > On 11/10/2018 16:34, Reshad Rahman (rrahman) wrote: > > > > > > Hi Rob, > > > > > > *From: *netmod <netmod-boun...@ietf.org> on behalf of "Robert Wilton > -X > > > *(rwilton - ENSOFT LIMITED at Cisco)" <rwil...@cisco.com> > > > *Date: *Thursday, October 11, 2018 at 7:17 AM > > > *To: *Martin Bjorklund <m...@tail-f.com> > > > *Cc: *"netmod@ietf.org" <netmod@ietf.org> > > > *Subject: *Re: [netmod] xpath expressions in JSON > > > > > > On 11/10/2018 11:50, Martin Bjorklund wrote: > > > > > > Robert Wilton <rwil...@cisco.com><mailto:rwil...@cisco.com>wrote: > > > > > > On 11/10/2018 11:21, Martin Bjorklund wrote: > > > > > > Andy Bierman > > > <a...@yumaworks.com><mailto:a...@yumaworks.com>wrote: > > > > > > On Wed, Oct 10, 2018 at 11:39 PM, Martin Bjorklund > > > <m...@tail-f.com><mailto:m...@tail-f.com> > > > > > > wrote: > > > > > > Andy Bierman > > > <a...@yumaworks.com><mailto:a...@yumaworks.com > >wrote: > > > > > > On Wed, Oct 10, 2018 at 6:59 PM, Reshad Rahman > > > (rrahman) < > > > > > > rrah...@cisco.com<mailto:rrah...@cisco.com>> > > > > > > wrote: > > > > > > On 2018-10-10, 9:59 AM, "netmod on behalf > > > of Martin Bjorklund" < > > > > > > netmod-boun...@ietf.org<mailto: > netmod-boun...@ietf.org>on > > > behalf of > > > m...@tail-f.com<mailto:m...@tail-f.com>> > wrote: > > > > > > Ladislav Lhotka > > > <lho...@nic.cz><mailto:lho...@nic.cz > >wrote: > > > > > > > Martin Bjorklund > > > <m...@tail-f.com><mailto:m...@tail-f.com > >writes: > > > > > > > > > > > > > > > Hi, > > > > > > > > > > > > > > > > While reviewing restconf-notif, I > > > saw this example: > > > > > > > > > > > > > > > > { > > > > > > > > > > > "ietf-subscribed-notifications:input": { > > > > > > > > "stream": "NETCONF", > > > > > > > > "stream-xpath-filter": > > > "/ds:foo/", > > > > > > > > "dscp": "10" > > > > > > > > } > > > > > > > > } > > > > > > > > > > > > > > > > Note the "stream-xpath-filter". > > > It has a prefix in the XPath > > > > > > string. > > > > > > > > How are prefixes declared when > > > JSON is used? > > > > > > > > > > > > > > > > The leaf "stream-xpath-filter" > says: > > > > > > > > > > > > > > > > o The set of > > > namespace declarations are those in > > > > > > scope on > > > > > > > > the > > > 'stream-xpath-filter' leaf element. > > > > > > > > > > > > > > > > (I think I provided that text...) > > > > > > > > > > > > > > > > This assumes that the encoding is > > > XML, or at leas that the > > > > > > encoding > > > > > > > > can somehow transfer namespace > > > declarations. > > > > > > > > > > > > > > It can't. There are two options: > > > > > > > > > > > > > > 1. have different representations > > > of this value in XML and JSON, > > > > > > > analogically to instance > > > indentifiers (sec. 6.11 in RFC 7951). > > > > > > > > > > > > > > 2. use a module name rather than a > > > prefix in XML, too. > > > > > > > > > > > > > > I would suggest #2. > > > > > > <RR> But that means making non-backwards > > > compatible change to the XML > > > > > > representation? > > > > > > Not really. It means NETMOD WG would be > > > creating its own special > > > > > > variant > > > > > > of > > > > > > XPath. > > > > > > Not at all. What I propose is perfectly fine, > > > legal XPath 1.0. > > > > > > XPath 1.0 says that an XPath expression is > > > evaluated in a context. > > > > > > One item in the context is a set of mappings from > > > <prefix> to <uri>, > > > > > > where <prefix> is used to lookup prefixes used in > > > the XPath > > > > > > expression, e.g. in "/foo:interfaces" "foo" is the > > > prefix. > > > > > > It is perfectly fine to say that the prefix > > > mapping set is this: > > > > > > "ietf-interfaces" -> > > > "urn:ietf:params:xml:ns:yang:ietf-interfaces" > > > > > > "ietf-ip" -> > > > "urn:ietf:params:xml:ns:yang:ietf-ip" > > > > > > and use that to evaluate the expression > > > > > > > > > /ietf-interfaces:interfaces/ > ietf-interfaces:interface/ietf-ip/ipv4 > > > > > > The XPath expression is normally parsed within an XML > > > instance > > > > > > document. > > > > > > There are "xmlns" attributes present that map the > > > prefix to a > > > > > > namespace URI. > > > > > > These mappings will not be present in the JSON at all.. > > > > > > A custom XPath implementation is required to magically > > > identify the > > > > > > prefix > > > > > > as a module name and magically find the namespace URI > > > for the module > > > > > > name. > > > > > > I disagree. You need an XPath implementation + custom > > > code to set up > > > > > > the environment. > > > > > > This is OK, but can we just use the JSON encoding instance > > > identifier > > > > > > format exactly? I.e .RFC 7951 section 6.11. > > > > > > So "/ietf-interfaces:interfaces/interface/ietf-ip:ipv4/ > enabled" > > > > > > can trivially be expanded to: > > > > > > "/ietf-interfaces:interfaces/ietf-interfaces:interface/ > ietf-ip:ipv4/ietf-ip:enabled", > > > > > > and then interpreted with the context: > > > > > > "ietf-interfaces" -> > > > "urn:ietf:params:xml:ns:yang:ietf-interfaces" > > > > > > "ietf-ip" -> "urn:ietf:params:xml:ns:yang:ietf-ip" > > > > > > *this* would require a custom XPath implementation. > > > > > > Why? I.e. how is this different from stating "Custom code is needed > > > to connect things together"? > > > > > > > > > and it is not obvious what the rules for the "auto-assignment" of > > > > > > prefixes would be. For example: > > > > > > /ietf-interfaces//ietf-ip:address[../foo] > > > > > > what is the prefix for "foo"? > > > > > > OK, so here the module for "../foo" would need to be specified. > > > > > > Perhaps the rule that I'm looking for is the module name may be > > > omitted when it matches the parent node module, and can easily be > > > inferred. I.e. so that for any XPath string, it is possible to > > > trivially expand it without any additional schema context. > > > > > > It just seems to be that requiring the long hand of > > > "/ietf-interfaces:interfaces/ietf-interfaces:interface/ > ietf-ip:ipv4/ietf-ip:enabled" > > > seems like it will get very verbose, and I wonder whether we are > > > introducing yet another Xpath format to YANG. > > > <RR> I’m willing to live with verbosity if it avoids the need of > > > another format. > > > > > RW: > > > > This is already looks like another format: > > Again, it is *not* another format! > > > > > > Xpath filters used in Netconf use explicit namespaces, e.g. rfc6241 > > sec 8.9.5.1 > > > > <filter xmlns:t="http://example.com/schema/1.2/config"; > > type="xpath" > > select="/t:top/t:users/t:user[t:name='fred']"/> > > </get-config> > > In this case, the prefix-string -> uri mapping is taken from the XML > namespace declaration in the XML document. > > > > The standard JSON encoding for instance-data (IIRC, the same scheme is > > used for CBOR) uses the module-name but omits it where it matches the > > parent (e.g. > > > > "/ietf-interfaces:interfaces/interface/ietf-ip:ipv4/enabled") > > Do you mean instance-identifier? If so, it is a special type that > happens to share the syntax with XPath, and the JSON syntax is defined > in RFC 7951 section 6.11. > > > > > RFC 8040 query parameter is as described below, but having looked at > > the examples I'm not really sure how that is meant to work :-) > > In this case, the prefix-string -> uri mapping is given in the > document. > > > We use XPath in various different places, and each place MUST specify > the evaluation context. > > You are right. Our custom XPath code needs to be told to get prefix mappings from XML or YANG import-stmts already, so 1 more internal mapping directly to module name is not going to require any significant changes to XPath processing. More importantly, it does not require any redefinition of the XPath standard. > > > /martin > Andy > > > > > Finally, I'm trying to figure out have RFC 8040 query parameter (sect > > > 4.8.4), which also uses XPath expressions is meant to work. That > > > states: > > > > > > > > > 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. > > > > > > > > > Yet the examples in section 8.3.6 don't seem to use namespace prefixes > > > in very many places, e.g. why is it "/example-mod:event1/name='joe'" > > > and not "/example-mod:event1/example-mod:name='joe'"? Is the example > > > wrong, or otherwise what am I missing? :-) > > > > > > <RR> Section 8.3.6 of which document? > > > > > RFC 8040. > > > > Thanks, > > Rob > > > > > Regards, > > > > > > Reshad. > > > > > > > > > Thanks, > > > Rob > > > > > > > > > > > > /martin > > > > > > Thanks, > > > > > > Rob > > > > > > There is no standard XPath implementation that can just > > > take an XML > > > > > > instance document + YANG module and figure out what to > > > do. Custom > > > > > > code is needed to connect things together. This proposal > > > doesn't > > > > > > change this. > > > > > > /martin > > > > > > A normal XPath implementation will not find any > > > namespace mapping for > > > > > > the > > > > > > prefixes. > > > > > > An XPath expression has no concept of the "current > > > module" inherited > > > > > > from > > > > > > the parent > > > > > > like the JSON encoding. This is problematic for > predicates > > > > > > /ietf-interfaces:interfaces/interface[name='eth0'] > > > > > > XPath says the missing prefixes for 'interface' and > > > 'name' are simply > > > > > > missing (no namespace). > > > > > > The JSON encoding says "ietf-interfaces" is used for > > > 'interfaces'. and > > > > > > 'interface'. > > > > > > There is no specification for the 'name' node inside a > > > predicate. > > > > > > So you must mean the full module name will be used at > > > every node: > > > > > > > > > /ietf-interfaces:interfaces/ietf-interfaces:interface[ > ietf-interfaces:name='eth0'] > > > > > > /martin > > > > > > Andy > > > > > > Hmm, so you mean change the leaf > > > "stream-xpath-filter" to say: > > > > > > o The set of namespace > > > declarations has one member for > > > > > > each > > > > > > YANG module supported by > > > the server. This member maps > > > > > > from the YANG module name > > > to the YANG module namespace. > > > > > > This means that in the > > > XPath expression, the module > > > > > > name > > > > > > serves as the prefix. > > > > > > .... and then also give an example of > > > this. > > > > > > This is probably what we need to do > > > in all places where > > > > > > yang:xpath1.0 > > > > > > is used, going forward. Maybe even > > > define a new type > > > > > > yang:xpath1.0-2 (name?) with the set > > > of namespace declarations > > > > > > built-in. > > > > > > We should avoid making off-the-shelf > > > implementations of standards like > > > > > > XPath unusable. > > > > > > At the very least this should be only > > > available if the server supports > > > > > > it > > > > > > (with a capability URI) > > > > > > <RR> So we need an update to RFC7951? > > > > > > Regards, > > > > > > Reshad. > > > > > > Andy > > > > > > /martin > > > > > > > > > > > > > > Lada > > > > > > > > > > > > > > > > > > > > > > > How is this supposed to work with > > > JSON? > > > > > > > > > > > > > > > > > > > > > > > > /martin > > > > > > > > > > > > > > > > > > > ______________________________ > _________________ > > > > > > > > netmod mailing list > > > > > > > > > > > netmod@ietf.org<mailto:netmod@ietf.org> > > > > > > > > > > > https://www.ietf.org/mailman/ > listinfo/netmod > > > > > > > > > > > > > > -- > > > > > > > Ladislav Lhotka > > > > > > > Head, CZ.NIC Labs > > > > > > > PGP Key ID: 0xB8F92B08A9F76C67 > > > > > > > > > > > > > > > > ______________________________ > _________________ > > > > > > netmod mailing list > > > > > > netmod@ietf.org<mailto:netmod@ietf.org> > > > > > > https://www.ietf.org/mailman/ > listinfo/netmod > > > > > > ______________________________ > _________________ > > > > > > netmod mailing list > > > > > > netmod@ietf.org<mailto:netmod@ietf.org> > > > > > > https://www.ietf.org/mailman/ > listinfo/netmod > > > > > > _______________________________________________ > > > > > > netmod mailing list > > > > > > netmod@ietf.org<mailto: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
