Robert Wilton <[email protected]> wrote: > > > On 11/10/2018 11:50, Martin Bjorklund wrote: > > Robert Wilton <[email protected]> wrote: > >> > >> On 11/10/2018 11:21, Martin Bjorklund wrote: > >>> Andy Bierman <[email protected]> wrote: > >>>> On Wed, Oct 10, 2018 at 11:39 PM, Martin Bjorklund <[email protected]> > >>>> wrote: > >>>> > >>>>> Andy Bierman <[email protected]> wrote: > >>>>>> On Wed, Oct 10, 2018 at 6:59 PM, Reshad Rahman (rrahman) < > >>>>> [email protected]> > >>>>>> wrote: > >>>>>> > >>>>>>> On 2018-10-10, 9:59 AM, "netmod on behalf of Martin Bjorklund" < > >>>>>>> [email protected] on behalf of [email protected]> wrote: > >>>>>>> > >>>>>>> Ladislav Lhotka <[email protected]> wrote: > >>>>>>> > Martin Bjorklund <[email protected]> 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"?
B/c the specification of XPath allows you to (actually, *requires* you to) construct the set of prefix strings to url mappings. This is "custom code to connect things". But changing the syntax means changin the specification. > > 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. I agree that it is very verbose. But do not mix XPath expressions in leaf values (which is what this thread is about) with instance-identfiers. > 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. Perfect! It seems the authors of 8040 thought of this ;-) > 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? :-) It seems the example is wrong! /martin _______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
