[netmod] YANG XPath usage guidelines (6087bis)

[Jernej Tuljak <[e-mail]>]

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?

'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'?

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 
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?

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] 
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