On 23/11/2018 13:29, Ladislav Lhotka wrote:
On Fri, 2018-11-23 at 13:39 +0100, Juergen Schoenwaelder wrote:
On Fri, Nov 23, 2018 at 01:02:03PM +0100, Ladislav Lhotka wrote:
Here is an attempt to rewrite things in a way according to how I
understand things works. It should be possible to describe what we
mean. If we can't do that, we have a bigger problem. (I have changed
only the last two sentences.)

OLD

    The leafref built-in 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.

NEW

    The leafref built-in 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 a leaf or
    leaf-list node in the data tree. The value space of the leafref
    node is determined by the value space of the schema tree node
The term "value space of a schema tree node" is not defined.
OK. So we say 'the value space of the type of the schema tree node'.
Yes, this is better. But what if the schema tree node is made invalid due to a
failed "when" expression? Does it still apply?

I might be being picky, but it isn't absolutely clear from the text which node "schema tree node" refers to.

Hence I wonder whether it might be better to say "...identify the referenced leaf or leaflist ..." and "value space of the referenced schema tree node".

Thanks,
Rob



    definining the referenced data tree node.
With require-instance=false there needn't be any referenced data tree node.
So we add "(irrespective whether the node exists or not).
If the data tree node doesn't exist, we cannot refer to the schema tree node
that defines it.

This likely is not perfect yet but perhaps we manage to make it
perfect. ;-) What is not yet clearly described I think is what
'further restricted by corresponding instance nodes in the data tree'
means (and that I think depends on require-instance). Perhaps add
Right. In this case it is not "further restricted" but rather there is a
discrete set of possible values.
A discrete set of possible values is a restriction so I do not
understand your comment. So here is the next iteration:
If required-instance is true, there is no need to care about all this tricky
stuff with schema tree nodes and their types. In other words:

1. if required-instance = true, the permitted values are obtained from the data
tree.

2. if required-instance = false, the corresponding schema node has to be
determined, and its type defines the permitted values of the leafref node.

It is an exclusive-or, #1 is not an "optional further restriction".

Lada

NEW:

     The leafref built-in 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 (see
     Section 9.9.3).  The "path" substatement (Section 9.9.2) is used
     to identify a leaf or leaf-list node in the data tree. The value
     space of the leafref node is determined by the value space of the
     type of the schema tree node definining the referenced data tree
     node (irrespective whether the referenced data tree node exists or
     not).

/js


_______________________________________________
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Reply via email to