Kent Watsen <[email protected]> writes: >>>1. In Section 3, it says: >>> >>><snip/> >>> Does this mean that the annotation A can be used by *any* module >>> the server advertises, or just the modules that define/import >>> annotation A? >> >>For all modules implemented by the server, no import is needed. > > > Good, but I think the text should say this explicitly.
OK. > > > >>> I assume that the intent is for the annotation to apply to >>> the server as a whole, not any specific module. It might >> >>Yes. The description can also say that the annotation is ignored >>elsewhere. > > 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? > > >>> help enforce this if annotations can only be defined in >>> modules that don't define any data-nodes and it is required >>> that the server advertises this module explicitly (not via >>> an import)... >> >>I expect this will be the normal way of defining annotations, and it >>could appear in the document as a guideline. I don't think though it is >>necessary to state it as a hard rule. > > OK, a SHOULD or RECOMMENDED statement would help to clarify this. > OK. > > >>>3. In Section 4.2.2, adding metadata to the first entry in a list doesn't >>> seem elegant. Can we instead create a special list element like the >>> following? >> >>Maybe I don't understand but the idea is that a separate metadata objects >>can be attached to any or all entries of a list. In the example it is >>added only to the first entry but another metadata object could be added >>to the second entry as well. > > 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. > > > > >>It is not possible to add an annotation to the whole list, also because >>this cannot be represented in XML encoding (via attributes). > > 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. > > 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. 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
