We vote NO for the progression of CD14769 Type Repository Function with the following comments. General ------- A. We consider the Type repository function standard necessary for the family of ODP standards. B. We consider the liaison with OMG as a very important channel for the further development and industrial exploitation of ODP standards. However, the basic modeling solutions of OMG and ODP-RM are not equal. Therefore, we find it unsatisfying that standards like the type repository function are designed solely from the OMG perspective. Such development restricts the future solutions for gaining benefits from the already existing ODP framework standards. In our detailed comments, the major goal is to improve the motivating and introductory parts in a way that brings forward the difference of OMG and ODP work. With this we wish to combine the industrial benefit of joining the de-facto standard of today with the de-jure standard that leads the future solutions. C. We consider that the current, OMG driven approach is at places too restrictive. We suggest that some of the implementation related material of the OMG MOF is not included to this standard. D. We consider the still missing aspects of type repository federations as an essential component of this standard. Detailed -------- 1. Clauses: 0 (Introduction) Status: Editorial Problem: para 6 sentence 2 broken 2. Clauses: 1, bullet 3 Status: Technical and major editorial Problem: The structure and scope of the text does not match the viewpoint language specifications. Suggestion: Replace the first sentence of bullet 3 with the following - provides enterprise and engineering specifications of a generic type repository function within the type description framework which can be specialised to select a specific type system or type notation. 3. Clauses: 2.2, 1st sentence Status: Technical and major editorial Problem: See comment B Suggestion: Replace with "This Recommendation | International Standard contains shared text with the Meta-Object Facility specification published by the Object Management Group, and hence makes references to the following specifications:" 4. Clauses: 3.3, 4 Status: Minor editorial Problem: Missing text Suggestion: Explain what MOF is. Add ODL to the list of abbreviations. 5. Clauses: 5 Status: Technical and major editorial Problem: See comment B Suggestion: Replace the current contents of clause 5 with a text that - names the type management problems in ODP systems - gives a definition of type repository - describes the architectural difference between ODP-RM and OMA - gives a definition of MOF as a specialisation - describes the usage of MOF with short sentences See Annex A for suggested text. The suggested text is based on the overview clause of the previous CD text, which has been enhanced with references to MOF. The suggested text contains the term "target concept". 6. Clauses: 6.2, temporary note Status: Editorial Suggestion: Role names like type-system type system description may be precise but their meaning does not communicate through, for example the slight difference of "type-system" and "type system". We suggest that short role names are used, and a more wordy explanation for the meaning of the role name is added. Also, the role objective descriptions could use other words than can be found in the role name, in order to allow readers to double-check they understanding of the name. 7. Clauses: 6.2.1 Status: Major editorial Problem: The relationship of the enterprise viewpoint structures to the rest of the document is unclear. Especially, the mapping of the ODP world and the MOF world is missing. Suggestion: a) Intertwine the term "set of target concepts" with type systems. b) Explain to what kind of users each level (in Figure 1) is useful. Application user exploits objects; application programmer exploits the level; application generator programmer exploits the uppermost layer. c) Add a note (or other explanation) that the objects in the layer structure can be reflective. d) Add a note (or other explanation) that the layers in Figure 1 correspond to the layers of MOF. e) Add a note (or other explanation) that the "type-system type system description" corresponds to the scope of this standard. 8. Clauses: 6.2.1.1 Status: Major editorial Suggestion: The clause specifies the syntactical structure, but it would be more readable if some explaining sentences or words were added. For example, in the first sentence: "A type repository community contains exactly one type repository role and exactly one type-system type system description that defines how the type repository is structured." 9. Clauses: 6.2.2.1-6.2.2.2 Status: Major editorial, technical for enterprise language Problem: The descriptions look like information viewpoint statements of information objects like various description objects. The earlier way of describing activities was more appropriate. Here, verification and publication are activity-like constructs and therefore those descriptions are more suited to the enterprise viewpoint. Suggestion: Basic behaviour is related to the objective of the community, and therefore obeys the structure of the contract. Basic behaviour could be described in groups supporting separately each subgoal of the community. For example: - behaviour for type community creation - behaviour for type publication - behaviour for type usage - behaviour for type verification 10.Clauses: 6 Status: Technical Problem: Missing federation descriptions Rationale: federation is defined in ODP-RM Part 3 as a community of domains. Therefore, type repository federation would be a community of type repository domains. domain is defined in ODP-RM Part 3 as a group of object with a characterisising relationship with a controller. Therefore, a type repository domain would be the set of type descriptions controlled by a single type repository. Each community have an objective. What are the objectives of a type repository federation? - hide the differencies of different description languages (language transparency?) - hide the differencies of different naming systems involved (naming transparency?) - hide the differencies of different type system structures (data representation transparency?) - support the availability of new type specifications added to various type repository domains (browsing facilities need to be supported?) Language federation - type checking, translation, asserted mappings Naming federation - mappings Representation federation - asserted mappings Browsing federation - needs the support of the previous ones, otherwise exploits the normal interfaces as they are Suggestion: Name the various federations and they objectives. Tell that the federations should normally be supported simultaneously. There may be need of adopting back some of the enterprise object from the previous CD version. There should also be a note telling that the federations are not currently supported by MOF, because, for example language federations are unnecessary in CORBA environments as CORBA IDL is used. 11.Clauses: 7, 7.1, 7.3, 8 Status: Major editorial Problem: The viewpoint languages are not used in a proper manner. Suggestion: Retitle clauses as follows 7 Abstract view 7.1. MOF Overview 7.3. Four layer metamodel architecture of MOF 8 Concrete view 12.Clauses: 7.6, Figure 3 Status: Editorial Problems: a) The figure and the related discussion are difficult to follow because it combines two separate aspects; the supported world of target concepts and the supporting world of meta-objects. In addition, the figure approaches the concepts from a different direction as the three layer MOF model presented before. b) Especially in Figure 3, the restrictions for the target concepts of ODP becomes visible. There should be some notes somewhere explaining these restrictions. c) The term "namespace" is not intuitively good, but missleading. We suggest the term "typeset" instead. d) BehaviouralFeature should be generalizable. 13.Clauses: 7.8 Status: Editorial Problem: The text says: "..., they are not strictly meta-metamodel constructs". Is there reason to have these CORBA specific basic types included to this standard? Suggestion: Remove. 14.Clauses: 7.12, 8.3 Status: Technical and major editorial Problem: Presents tools for CORBA environments, out of the scope of type repository function. Suggestion: Remove 15.Clauses: 7.15 Status: Technical and editorial Problem: The extension mechanism for MOF is certainly needed in this standard. However, this description is no more at the engineering level, but on a technology level. Thus the text is not suitable as it stands, but a more abstract level description that would allow other similar solutions would be. 16.Clauses: 7.16 Status: Technical Problem: Not suitable for inter-repository cooperation in ODP. Suggestion: Remove and replace with something in consistence with the enterprise viewpoint. 16.Clauses: 8.3.2.2 Status: Technical Problem: Not appropriate for this standard. Suggestion: Remove.