Re: [netmod] YANG XPath usage guidelines (6087bis)

[Ladislav Lhotka <[e-mail]>]

Jernej Tuljak <[e-mail]> writes:

> Hi,
>
> some questions about YANG XPath expressions in general and as observed 
> by 6087bis [1].
>
> Does it make sense to use the 'id(object)' and 'lang(string)' XPath 
> functions in YANG XPath expressions? They both imply existence of XML 
> attributes, which cannot be modeled in pure YANG. Shouldn't RFC6087bis 
> include a guideline for those in Section 4.5.? Is there a case where the 
> mentioned XPath functions could be used?

Now that there are several proposals for standardizing (global)
attributes for use with YANG data, it might actually be useful to refer
to attributes in XPath expressions. One use case could be: "Nodes X and
Y can both be present only if at least one of them is tagged as
inactive".

But in order to be able to do this, one needs to be able to include an
attribute's namespace in the context of the XPath expression - this is
another case where the "attribute" statement (issue Y33) would be useful.
 
>
> 'local-name(node-set?)', 'namespace-uri(node-set?)', 'name(node-set?)', 
> 'string(object?)' and 'number(object?)' are all directly reliant on 
> document order when the argument evaluates to a node-set with size > 1 
> and may therefore return different results for different 
> implementations, like the case with 'position' and 'last'. Other 
> functions may also be indirectly reliant on document order when they are 
> supplied with a node-set argument which then needs to be converted into 
> a string or a number as if by calling 'string(object?)' or  
> 'number(object?)' respectively [2]. Shouldn't this also be mentioned in 
> the guidelines, since some other cases are?
>
> Axes 'preceding-sibling' and 'following-sibling' should not be used 
> unless dealing with user ordered lists or leaf-lists and I agree with 
> 6087bis, however document order may not be relevant when using those two 
> axes (uniqueness checks). There's an example in ietf-routing module [3]:
> not(/routing/ribs/rib[name=current()/preceding-sibling::connected-rib/rib-name 
> and 
> address-family=/routing/ribs/rib[name=current()/rib-name]/address-family])
> where current() evaluates to a non-user ordered list instance. Shouldn't 
> this also be mentioned in the guidelines as an acceptable corner case, 
> like it is for 'preceding' and 'following'?

I think the following text in 6087bis should be extended to cover
"preceding-sibling" and "following-sibling" as well:

"The 'preceding' and 'following' axes MAY be used if document order is
not relevant to the outcome of the expression (e.g., check for global
uniqueness of a parameter value)."

>
> 6087bis specifies:
>
>     XPath expressions for 'when' statements MUST NOT reference the
>     context node or any descendant nodes of the context node.
>
> yet ietf-ipv4-unicast-routing [3] clearly does so, with it's
> conditional

The example in sec. 3.3 of RFC 7223 does it, too.
 
> augments of rpc methods, where it references 'rt:address-family' which 
> is a descendant of the initial context node (augmentation target or 
> nearest data node ancestor). Shouldn't conditional augmentation be an 
> exception to this paragraph?

Yes. In fact, many of the concerns regarding "when" (see e.g. issue Y18)
don't apply if it is used under "augment" because the result of "when"
evaluation doesn't affect the context node.

>
> 6087bis specifies:
>
>     Data nodes that use the 'int64' and 'uint64' built-in type SHOULD NOT
>     be used within numeric expressions.  There are boundary conditions in
>     which the translation from the YANG 64-bit type to an XPath number
>     can cause incorrect results.  Specifically, an XPath 'double'
>     precision floating point number cannot represent very large positive
>     or negative 64-bit numbers because it only provides a total precision
>     of 53 bits.  The 'int64' and 'uint64' data types MAY be used in
>     numeric expressions if the value can be represented with no more than
>     53 bits of precision.
>
> In XPath specification [4], term "numeric expressions" refers to 
> additive (+, -), multiplicative (*, mod, div) or unary expressions 
> (sign) and does not include relational or equality expressions, so 
> comparisons of int64 and uint64 data nodes do not seem to be discouraged 
> by the current text. Was this intentional? Shouldn't all such numeric 
> conversions be avoided?
>
> Ladislav once mentioned [5] that YANG XPath is able to "break out of 
> module containment" with an expression like
> /*[local-name()='foo']
> which is quite dangerous and IMO deserves mention in the guidelines. It 
> should be clear that an expression is only able to reference names 
> defined within the scope of a module, right? Or was "breaking out of
> module containment" intended as a feature of RFC6020 (seems more like a 
> bug to me)? Completely unrelated modules should not cause unwanted side 
> effects when implemented together.

+1

Lada

>
> [1] 
> http://tools.ietf.org/html/draft-bierman-netmod-rfc6087bis-00#section-4.5
> [2] http://www.w3.org/TR/1999/REC-xpath-19991116/#section-Function-Calls
> [3] http://tools.ietf.org/html/draft-ietf-netmod-routing-cfg-15
> [4] http://www.w3.org/TR/1999/REC-xpath-19991116/#numbers
> [5] http://www.ietf.org/mail-archive/web/netmod/current/msg09623.html
>
> Jernej
>
> _______________________________________________
> netmod mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/netmod

-- 
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C