Contribution to Open Distributed Processing -- Type Repository Function ----------------------------------------------------------------------- We recommend the following changes in the current working document "ISO/IEC JTC1/SC21 N10389 Open Distributed Processing -- Type Repository Function". The major comments in our contribution are: - the major statements of the standard are difficult to find, and the readers should be given a better overview, - the type framework expressed in Table 1 in Clause 5 is incorrect, - the two semantic abstraction levels in information viewpoint should be clearly separated, - conformance statements are missing, and - mutability policies should be applied to relationships, too. Item: 1 Clauses: 2 Suggestions: Add reference to ODP Naming framework. Item: 2 Clauses: 5 Rationale: Readers find it difficult to find out what the substance in this stardard is. In addition, the overview is given in a format "what the standard writer shall do". Suggestions: Rewrite the Clause 5 so that it gives only the key components of the type repository function. The text should point out the importance of the type descriptions and the relationships between the type descriptions. The fact that relationships bind together descriptions from different computing systems (federation) should be stressed. Rephrase motivation in a form that it tells what the standard already includes. Item: 3 Clauses: 5, paragraph 5 Suggestions: Remove COBOL and SQL from the list in the second bullet. Item: 4 Clauses: 5.1., first bullet; titles of 9.2.1, 9.2.2. Rationale: Contradiction of terms. Suggestions: Replace in 5.1. "The set of abstract types (ODP concepts) is open-ended." with "The sets of abstract types and ODP concepts are open-ended." Rename ODP concepts to meta-concepts in 9.2.1. and 9.2.2. Add an explantation that meta-concepts include at least the ODP concepts but can for instance in TINA environment include essential TINA concepts too. Item: 5 Clauses: 5, 6 Rationale: Typical structure of an ODP standard is that the Chapter 5 is the full overview and the Chapter 6 is already the enterprise viewpoint. Suggestions: Use the following structure of Chapter 5: 5. Overview 5.1. Motivation < current clause 5 > 5.2. Summary of fundamental principles < current clause 5.1.> 5.3. ODP Type framework < remove editors note and include the text below > The type repository function must respect the basic classification of ODP concepts related to types. Currently these concepts include those identified in Figure x (include illustrations from annex), but the set of ODP concepts need to be open-ended. Furthermore, the standard will include operations for modifying this type framework. Item: 6 Clauses: 6, table 1 and Annex "Model 1: Computational type overview" Rationale: The contents of the table and figures does not properly reflect the essential ODP concepts that are related to types. Suggestions: Interface type contains behaviour type and signature type. Primitive binding, compound binding, primitive operation binding, primitive signal binding, and primitive stream binding types are properties of other objects or supertypes of object type. Binding object type is supertype of object type. Compound binding type is not needed. Is there a reason to exclude template types? Item: 7 Clauses: Editor note in the end of clause 6 Suggestions: Definition of signature type that captures the interface, operation and flow signatures would be beneficial. Environment contract type should be a template not a type. Behaviour type and action type are supertypes of the object type. Property type and role type are supertypes of data type. Item: 8 Clauses: Editor note in clause 7.1 Rationale: The inconsistency arises from the last sentence that makes a statement that belongs to a different viewpoint and at a totally different level of abstraction. Suggestions: Remove the last sentence of 7.1. Item: 9 Clauses: 7.3 Rationale: Simplicity of the text. Suggestions: Do not repeat for each role "a role which". Item: 10 Clauses: 7.6., type derivation. Rationale: Needs clarification. Suggestions: Describe what derivation means. Item: 11 Clauses: 7.6, role type deletion. Suggestions: Replace "publishes" with "published". Item: 12 Clauses: 7.6, 7.7. Rationale: Mutability policy should be discussed in rules. Suggestions: Move the last 4 paragraphs of 7.6. (starting "There are some circumstances ...") to 7.7. and phrase as rules. Item: 13 Clauses: 7.6, last paragraph. Rationale: Statement too strong. Suggestions: Replace "No type specification or relationship should have a dependency on a type specification or relationship that has a weaker mutability policy." with "A type specification or relationship is not allowed to claim a stronger mutability policy than the type specifications or relationships that it depends." Item: 14 Clauses: 7.7. Suggestions: Add rules for type derivation. For example, level of immutability can not increase. Add rules for other activities, too. Some of the rules have already been included in activity list in clause 7.6. Item: 15 Clauses: 7.7, last sentence on page 16 Rationale: Includes undefined terms. Suggestions: Remove the sentence. Item: 16 Clauses: Editor notes in clause 7.7. Suggestions: Delete both sentences that have been questioned by the editor. Item: 17 Clauses: 7, 8 Suggestions: Also relationships should have immutability policy. The information viewpoint should also mention the mutability policies of types. Item: 18 Clauses: 6, 8 Suggestions: The table 1 from clause 6 should be described in the information viewpoint. Item: 19 Clauses: Through clause 8 Suggestions: Give a clause number for each schema. Item: 20 Clauses: Through clause 8 Severity: Conceptual Rationale: There are two levels of abstraction visible in the information viewpoint, a mathematical ideal of a global type repository and a more computational abstraction where the global set of type definitions is distributed. Both views are needed, but the text should explicitly state the difference of these abstractions. A type description of the mathematical view is distributed to several type repositories in the less abstract world. Item: 21 Clauses: 8 Suggestions: The contents of table 1 in clause 5 should be stated in information viewpoint, invariant and static schemata. Item: 22 Clauses: 8.1, page 19, paragraph 2 Rationale: The statement is too strong. Suggestions: Replace "A type description set is a set of all type descriptions of the same type expressed in all type languages." with "A type description set is the total collection of all potential descriptions in all potential languages for the type." Item: 23 Clauses: 8.2. Rationale: Editor's question. Suggestions: Yes, the two paragraphs present conformance statements. However, the sentences also present static schemata. Item: 24 Clauses: 8.3 Suggestions: Replace the first sentence "Before the schemas are defined, the following three schemas are introduced ..." with "Before the dynamic schemata are defined, the following three Z schemata are introduced ..." Item: 25 Clauses: 8.3, last paragraph on page 22 Rationale: See comment on 9.1.2. Change the text here in 8.3. so that it implies that identifiers are defined in another standard, not in another viewpoint. Item: 26 Clauses: 9, All IDLs. Rationale: Portability to different languages. Suggestions: Remove underscores from identifiers. Item: 27 Clauses: 9.1.2 Rationale: Editor's question. Suggestions: The type repository identifier need to be a name. For names, a reference to the naming framework should be given. In there, we suppose the name is defined as being an local identifier supplemented with an interpretor identifier. (Compare also with interface references.) Item: 28 Clauses: 9.1.3 Suggestions: These operations are specified in other standards, add reference. Item: 29 Clauses: 9.2.1 Suggestions: Use iterators for returning lists in the similar way that was used in trading function. Item: 30 Clauses: 9.7. and 9.7.1. Rationale: Inconsistency in the text. Suggestions: Integrate the comments of clause 9.7.1. to clause 9.7. Item: 31 Clauses: 9.7.1. Rationale: Editor's question in 9.7.2. Suggestions: There seems to be an extra field in trans_result. The trans_quality should appear only in the request, in reply it is superficial. In the enum trans_quality the alternative none should have a comment "no translation required". For the trans_outcome fields should we preferably use the same names as we use for the fields in trans_quality. Item: 32 Clauses: 9.11.1 Rationale: Editor's question. Suggestions: Relationships should be between definitions. Item: 33 Clauses: 9.15 Rationale: Editor's question. Suggestions: The system of ODP-concepts should be very small. Essential concepts are only: - object - template - type - interface - behaviour - signature - data The essential relationships are restricted to - conformant with (logically equal, belongs to the same equivalence class with) X, - subtype, supertype of X, and - a representation of X. Item: 34 Clauses: 9.17 Rationale: First temporary note. Suggestions: The inspiration should be searched from the binding framework instead. Environment contracts for interrogations limit the time used for looping in the network of type repositories. The query itself terminates in a finite time. Item: 35 Clauses: 9.17 Rationale: Last temporary note. Suggestions: The immutability policy should relief the implementations from propagating changes. A informative note could be included. Item: 36 Clauses: 10 Rationale: Need for conformance statements. Suggestions: There should be several levels of conformant type repositories. The smallest set of conformance requirements must include queries for type descriptions, queries for type conformance, and representation of immutability policy. Most importantly, all type repositories must be able to state relationships between types (able to federate in a simple way). The first level of conformance need not necessarily support subtyping relationships, and may work out conformance of interfaces plainly based on signatures. However, all type repositories should be able to state their own properties. The properties should include - whether subtyping is supported, - which description languages are supported, - what components of interfaces are considered in conformance checking, - what are the QoS attributes of the type repository service itself. Other, higher levels of conformant type repositories may include publication operations, deletions, etc. Additional services like translations need not to have conformance statements in this standard.