Hi,
that "path" statement should be reported as an error due to the
following text in RFC 8791:
The XPath document element is the augmented extension
statement itself, such that the child nodes of the document
element are represented by the data-def-stmt substatements
within the augmented 'structure' statement.
The context node of the 'augment-structure' statement is
derived in the same way as the 'augment' statement, as defined
in Section 6.4.1 of [RFC7950]. This conceptual node is
considered the context node for the following YANG statements:
- must-stmt
- when-stmt
- path-stmt
- min-elements-stmt
- max-elements-stmt
- mandatory-stmt
- unique-stmt
- ordered-by
- instance-identifier data type
While RFC 7950 allows multiple (document) root node children in its
repurposed XPath model [1], it is clear (enough) that there can only
ever be one such child in the case of each
"sx:structure"/"sx:augment-structure". The term "document element"
refers to this child and is defined in [XPATH]. Though this could have
been stated in clearer terms within RFC text. RFC 8791 does not list
[XPATH] as a normative reference, it is only listed as such in RFC 7950
(a normative reference of RFC 8791).
If XPath expressions used within "sx:structure"/"sx:augment-structure"
definitions would be able to target data nodes in configuration and
operational state, RFC 8791 would need to state this explicitly somehow
with something like the following, which for example applies to
"notification" definitions in RFC 7950:
o If the XPath expression is defined in a substatement to a
"notification" statement, the accessible tree is the notification
instance, all state data in the server, and the running
configuration datastore. If the notification is defined on the
top level in a module, then the root node has the node
representing the notification being defined and all top-level data
nodes in all modules as children. Otherwise, the root node has
all top-level data nodes in all modules as children.
There is no such text. This would also not be in line with the intent of
"sx:structure", as described in Section 1 of RFC 8791 [2], which among
other things says this:
There is no assumption that a YANG data structure can only be used
as a top-level abstraction, and it may also be nested within some other
data structure.
[1] https://datatracker.ietf.org/doc/html/rfc7950#section-6.4
[XPATH] https://www.w3.org/TR/1999/REC-xpath-19991116/#root-node
[2] https://datatracker.ietf.org/doc/html/rfc8791#name-introduction
Jernej
On 04/04/2025 09:03, Kristian Sallberg (krisallb) wrote:
Looking for guidance regarding this case. I interpret RFC8791 as it
allows (or at least does not explicitly forbid) the YANG embedded in
this github issue. What's your take?
https://github.com/CESNET/libyang/issues/2375
<https://github.com/CESNET/libyang/issues/2375>
yanglint can't find absolute path leafref target when defined within
sx:augment-structure · Issue #2375 · CESNET/libyang
<https://github.com/CESNET/libyang/issues/2375>
Reproducible with: yanglint 3.7.8 This YANG should be valid AFAICT but
yanglint can't find the leafref's target: module example {
yang-version 1.1; namespace "ex:ample"; prefix example; import ietf...
github.com
Best regards,
Kristian
_______________________________________________
netmod mailing list --netmod@ietf.org
To unsubscribe send an email tonetmod-le...@ietf.org
_______________________________________________
netmod mailing list -- netmod@ietf.org
To unsubscribe send an email to netmod-le...@ietf.org
