Kent Watsen <[email protected]> writes:
>>>>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....
A single namespace is essentially the same as a single module, isn't it?
But don't get mw wrong, syntactically annotations would be allowed
everywhere although in some places they may be a no-op.
>
>
>
>>> 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.
>
I don't understand. There is no special section for list entries/instances, this
is included in the section 4.2.2 (Adding Annotations to Anydata,
Container and List Instances). I agree an example should be included for
each data node type, i.e. container, list and anydata.
As for the list example, I think it is also important to show that some
entries may be decorated with annotations while other aren't.
>
>
>>>>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?
This is also valid, see sec. 7.7.6 in RFC 6020:
<foobars>
<foo>...</foo>
<bar>...</bar>
<foo>...</foo>
<bar>...</bar>
<bar>...</bar>
<foo>...</foo>
</foobars>
>
> 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.
This would mess up all standard XML tools.
> 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>
>
A processing instruction would be slightly better but yes, it's ugly.
>
> 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?
But that means XML clients would be unable to receive some
information. Is it what we want?
Lada
>
>
> Thanks,
> Kent (as a contributor)
>
>
>
>
>
--
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C
_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
