On Thu, Jun 02, 2016 at 04:14:56PM -0400, Dale R. Worley wrote: > 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".
I think the first sentence is potentially misleading (the "path" expression does not contain arbitrary XPath) and the second sentence is really hard to parse - if it makes sense at all the way it is written. > 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. Martin's original text says 'schema node' so there is not confusion that I see. The referred node is in the schema tree, not in the data tree. > 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? I think we should go with Martin's text and close this issue. > 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..." I would leave this is Martin's discretion (since he knows best whether this causes inconsistencies with other wordings in the document). Martin, how close are we to have a final version addressing all the review comments we received during the journey through the IESG? /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 <http://www.jacobs-university.de/> _______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
