Annex A: Comments for ODP Naming Framework
(ISO/IEC JTC1/SC21 N10390)


    General

  1. The ODP-RM offers viewpoint languages for discussion of (computing) systems. Naming framework is such a system, although an abstract framework -- similarly as the ODP-RM itself. The use of viewpoints in this standard would be important both for the completeness of the naming framework and the plausibility of ODP-RM.

  2. The order in which the important concepts of naming are presented is not logical. The current text contains a lot of evaluative material that makes some of the definitions ambiguous. For instance, the relationship of context and domain is ambiguous.

  3. The standard is missing all definitions that can be generated from information viewpoint dynamic schemata. Such definitions would clarify the possibilities of changing local names, changing names of contexts, and changing or establishing federations between name servers.

  4. The standard does not yet express quality of service aspects of names and name services. These aspects should be included.

    The type repository function expresses need for immutability policy of names. We support the inclusion of immutability related policies to this standard.

    Clause 0

  5. The introduction should position the naming framework wihin the RM-ODP. The current material only discusses benefits of context-relative naming. This material would be suitable for a tutorial and should be removed from this standard.

    Clause 3

  6. Terms "context-relative naming" and "global naming" should be included to the list of defined terms (clause 3.2.) and defined in the enterprise viewpoint specification.

  7. The layout of the document does not follow the template for the ISO standards and the document includes some editorial mistakes:

    1. The enumeration of items in clause 3 is illogical.

    2. Basic naming concepts in clause 7 are not all listed in clause 3.2.

    3. Usage of binding and unbinding in clause 3 is illogical.

    4. Terms that are redifined in this standard (naming graph, name space, naming context, naming graph, ...) should be removed from the list in clause 3.1.1.

    5. Naming graph appears twice in clause 3.2.

    6. Table of contents and index are missing.

    Clause 6

  8. The introduction contains a lot of tutorial material that justify why some solution techniques should be chosen. Instead, clear statements of the selected techniques should be given. (Motivation of these selection could be given after this as a separate sub-clause.)

  9. Naming is not clearly separated from trading. Some of the material is clearly out of ANSA Trading documents. The document should in the introduction material (clause 6) express the relationship of naming and trading.

    Clause 7

  10. In the current document name is sometimes a relationship between a linguistic term and an entity, sometimes a term only. Replace the definition of name in 7.1 by "Name is a relation between a term and an entity. Term is a linguistic construct (entity)."

  11. Naming context (clause 7.5) should be redefined: "A naming context is defined by a set of possible terms (a single namespace generated by a naming convention), a set of nameable entities, and a naming relation. The naming relation associates a set of terms in use and a set of entities named. In general, not all terms are used, and not all entities are named in a particular context."

    This defines context as a 3-tuple (T, N, E) where T is a term space (name space), E is a set of interesting entities that can be named, and N is a relation between individual elements of T and E. The presence of T and E is important because the sets can be restricted by an arbitrary convention. N is a set of names.

  12. The examples that describe what names can be used for (clause 7.1.1.) could be more exhaustive: they only represent a direct name (address), but do not mention at all the possibility of having a sequence of names at different abstraction levels. However, currently it already is common to have sequences that denote name-identity and identity-address mappings. Such sequences are important for example in mobile solutions.

  13. Replace definition of domain in clause 7.10: "Naming domain is derived from a naming context by defining a subset (N(d)) of naming relation (N) so that all names in N(d) are contolled by a single controlling object. The derived naming domain is the 3-tuple (T, N(d), E)."

  14. In clauses 7.6 and 7.7 replace "name" with "term".

  15. In a distributed environment where autonomous systems interwork, communication is not always successful nor always allowed. Therefore, also naming activities should be modelled in a way that the terminations would cover also cases of uncertainty. For example, in name comparison the cases are (i) names refer to the same object, (ii) the names do not refer to the same object, (iii) no comments (for example, for policy reasons), and (iv) comparison failed (for example, because name server did not respond).

    Clause 11

  16. Federation model encourages costly implementations of the naming services. A more neutral model is needed. A view concept could be used instead of export and import contexts.

  17. Federation of name servers should either be more detailed or refer to the binding framework standard. However, it is probable that the binding framework standard intends to refer to the naming framework. The establishment of initial federations should be described in one of these standards. When positioning this question, also security framework should be considered as it has strong effect on the configuration of initial federations.

  18. Because the relationship between contexts and domains is ambiguous also the representation of federations is difficult to follow. In addition, some of the important material is only presented in the annexes that are not an integral part of the standard.

  19. The annexes offer several methods for federative naming. However, the methods are not alternative, instead there is a model that is able to capture all of them. That model has not been yet presented by the standard. Presentation of that model and derivation of the current federation methods from it would be beneficial for the tenability of the standard.

    Annexes

  20. Mapping to existing naming systems. The mappings that are presented in annexes should represent counterparts of domains, contexts, names, and federation establishment processes. The mappings should also state in which degree the system allows dynamic changes of names, contexts, and name server federations.