Re: [netmod] xpath expressions in JSON

[Robert Wilton <[e-mail]>]

Hi Juergen,

Is this the same as Martin's alternative B proposed previously 
(attached)?  Or are you suggesting a different alternative?

Thanks,
Rob


On 23/10/2018 10:28, Juergen Schoenwaelder wrote:
> On Tue, Oct 23, 2018 at 11:20:54AM +0200, Ladislav Lhotka wrote:
>> Note that the namespace information needn't be sent along with every XPath
>> expression as it would probably be the case in the XML encoding of option A.
>> Only if a new namespace is being used, the "namespace" list has to be updated.
>>
> Can we pre-populate the context with namespaces, for example,
> controlled via an extension of yang library? Perhaps we can simply
> pre-polutate contexts with all module names? Yes, I know this makes
> xpath expressions rather verbose but on the other hand it takes away
> guesswork and (client) tools may do expansion of an unprefixed
> expression into a proper namespace prefixed expression.
>
> /js
>

--- Begin Message ---

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
[e-mail]
https://www.ietf.org/mailman/listinfo/netmod
.

--- End Message ---