On 10/15/18 4:25 PM, Ladislav Lhotka wrote:
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.
Not all XPath expressions map to something meaningful in the context of
YANG data. However a subset of them do.
IMO introducing yang:ypath1.0 makes sense but it is practical to define
it as a subset of yang:xpath1.0. Martins proposal 2) for an encoding
independent solution where the prefixes are restricted to be module
names works. Proposal 1) seems to be a step back clogging YANG with
encoding specific details.
Vladimir
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
_______________________________________________
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
