Juergen Schoenwaelder writes:
>On Tue, Sep 06, 2016 at 02:50:19AM +0000, Sterne, Jason (Nokia - CA) wrote:
>> I did manage to find some older posts about empty types in keys. It
>> seems that perhaps YANG 1.1 allows them but they are not actually
>> useful.
>Yes. Note that there are other constructs that are legal but not
>useful (a list key leaf with a type that only allows a single value
>is very close to list key leaf of type empty).
No, a missing key is worse, since the spec requires that all keys
must appear (7.8.6: 'If all keys are not specified for a list entry,
a "missing-element" error is returned.' Also 8.3.1). A key that
only allows a single value may be useless, but it makes data that
can be consistently manipulated. Is there a change in 7950 for
handling these?
In a similar node, while looking in 7950 for a such a rule, I saw the
following in 9.13.4:
/* instance-identifier for a list entry where the second
key ("enabled") is of type "empty" */
/ex:system/ex:service[ex:name='foo'][ex:enabled='']
But XPath says (4.2):
A node-set is converted to a string by returning the string-value
of the node in the node-set that is first in document order.
If the node-set is empty, an empty string is returned.
So if no <ex:enabled> elements are present, then the expression
ex:enabled selects an empty node set, and the string comparison
forces a conversion to type string, which generates an empty string.
Unless I'm off, the line should be fixed to avoid the string
conversion:
/ex:system/ex:service[ex:name='foo'][ex:enabled]
and a negation should be:
/ex:system/ex:service[ex:name='foo'][not(ex:enabled)]
Thanks,
Phil
_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
