Martin Bjorklund <m...@tail-f.com> writes:
> Ladislav Lhotka <lho...@nic.cz> wrote:
>> On Wed, 2018-10-10 at 19:23 -0700, Andy Bierman wrote:
>> >
>> >
>> > On Wed, Oct 10, 2018 at 6:59 PM, Reshad Rahman (rrahman)
>> > <rrah...@cisco.com>
>> > wrote:
>> > > On 2018-10-10, 9:59 AM, "netmod on behalf of Martin Bjorklund" <
>> > > netmod-boun...@ietf.org on behalf of m...@tail-f.com> wrote:
>> > >
>> > > Ladislav Lhotka <lho...@nic.cz> wrote:
>> > > > Martin Bjorklund <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.
>>
>> The thing is that XPath is "XML Path Language", so using it outside XML is
>> problematic.
>
> Not necessarily. Section 5 of the XPath 1.0 spec defins the "data
> model" where an XPath expression is applied. We could make a formal
> specification of how a YANG data tree maps to this data model (pretty
> straightforward...). I think experience from implementations over the
> last 8 years show that this in fact works quite well.
Except some parts that don't apply. For example, siblings nodes in XPath
are ordered, whereas in YANG 'foo[1]' may give unpredictable results.
This is probably OK in YANG modules but not so much if XPath expressions
are used as configuration data.
Lada
>
>
> /martin
>
>
>
>>
>> Lada
>>
>> >
>> > > 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
>> > > > > https://www.ietf.org/mailman/listinfo/netmod
>> > > >
>> > > > --
>> > > > Ladislav Lhotka
>> > > > Head, CZ.NIC Labs
>> > > > PGP Key ID: 0xB8F92B08A9F76C67
>> > > >
>> > >
>> > > _______________________________________________
>> > > 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
>> >
>> >
>> --
>> Ladislav Lhotka
>> Head, CZ.NIC Labs
>> PGP Key ID: 0xB8F92B08A9F76C67
>>
--
Ladislav Lhotka
Head, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67
_______________________________________________
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
