Martin Bjorklund <mbj at tail-f.com> wrote:
> Also, the text needs to mention leaf-lists. This gives:
>
> The leafref type is restricted to the value space of some leaf or
> leaf-list node in the schema tree and optionally further restricted
> by corresponding instance nodes in the data tree. The "path"
> substatement (Section 9.9.2) is used to identify the referred leaf
> or leaf-list node in the schema tree. The value space of the
> referring node is the value space of the referred node.
>
> If the "require-instance" property is "true", there MUST exist an
> node in the data tree, or a node with a default value in use (see
> Section 7.6.1 and Section 7.7.2), of the referred schema tree leaf
> or leaf-list node with the same value as the leafref value in a
> valid data tree.
>
> If the referring node represents configuration data, and the
> "require-instance" property (Section 9.9.3) is "true", the referred
> node MUST also represent configuration.
How about:
The leafref type contains an XPath expression in the "path"
substatement. Due to the restrictions on the expression, all
instances in the result set of the expression evaluated on all
possible data tree are instances of one single data node, called the
"referred node".
The leafref type has the value space of the type of the referred
node.
If the "require-instance" property is "true", the leafref type also
imposes a constraint on any node of its type: the value must be the
same as that of some instance in the data tree, or an instance with
a default value in use, selected by the XPath expression. Such a
constraint is enforced according to the rules in Section 8.
If the referring node represents configuration data, and the
"require-instance" property (Section 9.9.3) is "true", the referred
node MUST also represent configuration.
I started with a discussion of the XPath expression to state explicitly
that all selected instances must be instances of one data node, and used
that to define "referred node". With that clarified, it's easier to
state the conditions that we care about.
I want to clearly separate the question of value space (which is
enforced roughly any time XML using the module is parsed) from the
constraint (which is enforced only at the times specified in section 8).
I do exploit the convention that default values cause instance nodes to
exist in the data tree in a sort of virtual sense, in that the XPath
expression can return them in its data set. But I think that is
consistent with the philosophy of Yang. Does that need to be stated
more explicitly?
Also, in the lexicon:
o anydata: A data node that can contain an unknown set of nodes that
can be modelled by YANG, except anyxml.
o anyxml: A data node that can contain an unknown chunk of XML data.
Both definitions should start with "a data node *whose instances* can
contain..."
Dale
_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
