>>>Maybe I don't understand your response, but if we agree that annotations
>> are a server-level thing (not module-specific), then I do not agree
>>that a
>> module's description should be able to say that an annotation should be
>> ignored in other modules.
>>
>
>It depends on the annotation's semantics, and it may be designed to do
>something only for certain node instances (such as leafs with union
>type), or for nodes in a given namespace etc. Do you think it may be a
>problem?
Those kinds of uses are fine, as they are not module-specific. I just
want to ensure we don't ever wind up with module-specific annotations....
>> I see, but then this make the example misleading. I thought it was
>>trying
>> to show how to place an annotation on the list as a whole. I see now
>> it says "list instance", but this seems uninteresting example, as list
>
>I will use "list entry" because the term "instance" in not defined in
>YANG.
>
>> instances are just nodes for which how to apply annotations is already
>> known - there's nothing special about the node being a list element -
>> right?
>
>Do you suggest to remove the second example in that section? But you
>also wanted to add an example on "anydata" that is arguable even more
>alike to a container.
Yes, an example for each item discussed (including anydata) is desired.
What I'm questioning here is why we need to discuss annotating list
entries at all, since they seem to follow normal rules. If true, I
recommend removing a special section for list entries/instances entirely.
>>>An annotation cannot be attached to a list as a whole? - that seems
>> fundamentally broken, though I understand why you say it cannot be
>>easily
>> represented in XML (via attributes). Should we consider alternative
>> representations?
>
>I agree it might be useful, and I was thinking about it but I haven't
>found any good way for encoding it in XML, also because in XML list
>entries can be interspersed with other elements.
Interspersed with other elements? - I don't understand. For instance,
assuming:
container foobars {
list foo {
...
}
list bar {
}
}
The XML would be:
<foobars>
<foo>...</foo>
<foo>...</foo>
<foo>...</foo>
<bar>...</bar>
<bar>...</bar>
<bar>...</bar>
</foobars>
Where is the interspersion?
As for how to place annotations on an XML list as a whole, I was thinking
we could use a fake first element. For instance, the following shows an
annotation on the "bar" list:
<foobars>
<foo>...</foo>
<foo>...</foo>
<foo>...</foo>
<bar color="red"/> // colors entire list "red" (notice empty
element)
<bar>...</bar>
<bar>...</bar>
<bar>...</bar>
</foobars>
But this is most likely illegal since it's not a valid instance document.
So then maybe we could use an XML comment like this:
<foobars>
<foo>...</foo>
<foo>...</foo>
<foo>...</foo>
<!-- annotation: bar color="red" -->
<bar>...</bar>
<bar>...</bar>
<bar>...</bar>
</foobars>
Ugh, this isn't great either. Anybody else have an idea?
>>That said, if unavoidable, the draft needs to call that out as a
>> limitation somewhere, because it wan't clear to me. Are there other
>> limitations that are not also not being called out?
>
>Well, one could e.g. think about structured annotations but this is
>again not exactly easy with XML attributes. I don't think though we can
>really call it limitations - after all, the motivation for this document
>was to "officialize" the use of XML attributes, so it would be a bit
>weird to to make it incompatible with them.
True, I'd rather we can find a solution for annotating XML lists. Until
then, the draft SHOULD explicitly call it out as not supported. Maybe
put in into an OPEN ISSUES section?
Thanks,
Kent (as a contributor)
_______________________________________________
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
