Editor's Draft Disposition of Comments CD2 19763-12 Version 3

ISO/IEC JTC1/SC32/WG2 N1783

Editor's draft disposition of comments CD2 19763-12 – Version 3

Serial MB Clause No./ Paragraph/ Type Comment (justification for change) by the MB Proposed change by the MB Draft disposition Subclause Figure/ of No./ Annex Table/Note com- (e.g. 3.1) (e.g. Table ment 1) 001 CA 00 All - Ge Canada approves the draft with the following No further action at this time comments. 002 CA 01 All - Ge Since the new template allows for text to be Canada asks that future ballot texts No further action at this time referenced using line numbers, we generated a line include line numbers so that all NBs can numbered version of the text which is attached at reference them. the bottom of this document, and we have referenced those line numbers in our comments. 003 CA 02 1 Scope Ed IDEF1X is IEEE Std 1320.2-1998 Add the reference. Accepted 004 JP 01 1 Scope te "'universe of discourse" should be a domain of Accepted interest. Since ISO/IEC 24707 Common Logic defines "universe of discourse" very specifically in contrast to "universe of reference", WG2 generally agreed that "a domain of interest" should be used, instead of "universe of discourse" when it is used in a general sense. 005 JP 02 1 Scope te "These are often referred to as logical models." Accepted Should be removed because; As a scope, this sentence is not necessary. The meanings of logical model and conceptual model vary, depending on persons who use them and they are confusing. 006 JP 03 1 Scope te "at the logical level" should be removed, because Accepted its meaning is not clear. 007 JP 04 1 Scope te "at the conceptual level" should be removed, Accepted because its meaning is not clear. 008 CA 03 4.2.3 Note Ed NOTES are supposed to be in 9pt font. Make the change here and to all other Accepted NOTES. [Use the Note Style from the STD template.] 009 GB 01 4.2.6 ed The definition is too 'physical' Amend to read: "component of a table Accepted (4.2.34) that is a collection of values all of the same defined data type (4.2.7)"

page 1 of 6 ISO/IEC JTC1/SC32/WG2 N1783

Serial MB Clause No./ Paragraph/ Type Comment (justification for change) by the MB Proposed change by the MB Draft disposition Subclause Figure/ of No./ Annex Table/Note com- (e.g. 3.1) (e.g. Table ment 1) 010 JP 05 4.2.8 te It should be "non-enumerated domain", rather than Not accepted – the name "described domain", if it is necessary “described domain” was described chosen for consistency with domain ISO/IEC 11179-3:2013 011 JP 06 4.2.8 te Based on this definition, a continuous domain such Accepted – will use an as real number is not a described domain, since a adaption of the definition from described set of all real number can be defined explicit ly. ISO/IEC 11179-3:2013 domain 012 GB 02 4.2.9 ed The definition confuses real world and modelling Amend to read: "'property of an Accepted concepts. information model element (4.2.20) that is a statement explaining the significance of this information model element (4.2.20) to the business and or organisation that is the subject of this information model (4.2.19)" 013 JP 07 4.2.17 te Based on this definition, a set of all real numbers Accepted – will use an can be enumerated domain, which is not discrete adaption of the definition from enumerated and strange in an intuitive sense of "enumerated". ISO/IEC 11179-3:2013 domain Even if it is infinite, it can be an enumerated domain as far as it is countably (enumeratedly) in finite? Isn't is enough to simply adopt "enumerated value domain" from MDR? 014 JP 08 4.2.20 NOTE te Base on the definition of entity type(4.2.16), it Accepted – amended to read cannot be an information model element, because “element of an information information it is not graphical nor textual representation. model (4.2.19) that may be model represented graphically and/or element textually” 015 GB 03 4.2.32 ed The definition should be compatible with that for Amend to read: "sequence of values in a Accepted column. table (4.2.34), one for each column (4.2.6) of the table (4.2.34)" 016 JP 09 5 Structure ed The abbreviated term "MFI Information model Accepted of MFI registration" needs to be defined. Information model registration

page 2 of 6 ISO/IEC JTC1/SC32/WG2 N1783

Serial MB Clause No./ Paragraph/ Type Comment (justification for change) by the MB Proposed change by the MB Draft disposition Subclause Figure/ of No./ Annex Table/Note com- (e.g. 3.1) (e.g. Table ment 1) 017 JP 10 5.1 ed The meaning of "appropriate" in " This model is This metamodel can be used for Accepted Overview of also appropriate for database structures that registering database structure MFI conform to the SQL Core specification." needs to specifications that conform to the SQL Information be clarified. Core specification. model registration 018 JP 11 5.1 Figure1 ed The bottom raw of each rectangle should be Accepted Overview of removed, because no operations are specified. MFI Information model registration 019 JP 12 After 5.1 te Sub clause"5.2 Association between MFI Accepted Overview of Information model registration and MFI Core and MFI mapping " and a relevant figure should be inserted. Information model registration 020 JP 13 5.2 Detail te This sub clause is not necessary, because almost Accepted: actions are: provided in everything except alternative names (Aliases) are each specified in MFI 10.  Clause 5.2 to be metaclass removed. As a standard, aliases are not necessary. definition  Aliases to be removed If aliases are specified, its conformance is not Clause 5.3 and metaclass clear. To claim a conformance, is it necessary to definitions to be support all aliases, or is it enough to support expanded to cover either a name or one of aliases ? linkages to the various techniques. 021 JP 14 5.3.1 Superclass ed "(defined in MFI Core and mapping)" should be Accepted Attribute "(from MFI Core and mapping)" to be consistent Model_Elem with other parts of MFI and MDR. ent 022 JP 15 5.3.1 Subclasses ed It should be removed. Accepted Attribute

page 3 of 6 ISO/IEC JTC1/SC32/WG2 N1783

Serial MB Clause No./ Paragraph/ Type Comment (justification for change) by the MB Proposed change by the MB Draft disposition Subclause Figure/ of No./ Annex Table/Note com- (e.g. 3.1) (e.g. Table ment 1) 023 JP 16 5.3.1 Aliases te Intuitively saying, a SQL column can be an Accepted - see response to Attribute attribute, but an attribute are not necessarily a SQL 020 (JP 13) column. So, SQL_Column is not appropriate as an alias for Attribute. Also, SQL_Schema at 5.3.4 Diagram, SQL_Data_Type at 5.3.5 Domain, SQL_Table at 5.3.8 Entity_Type are strange for aliases.

Generally speaking, no alias is necessary. 024 JP 17 5.3.1 Attribute ed It should not be in oblique style.. Accepted. In Clause 5.2 the Attribute purpose of the italics was Name explained as representing and all other ‘inherited’ attributes. metaclasses Discussion at resolution centred on the fact that the identifiers in MDR may be different to the name (or other metaclass attributes in this part) and, therefore, they are attributes in this part and not inherited attributes. Resolution is, therefore, to remove all italics and references to ‘inheritance’ from MDR. 025 JP 18 5.3.1 Attribute te The meaning of "unique" is unclear. Accepted – “unique” to be Attribute removed throughout where it Name At least, there are two possibilities. One is globally is implying that a name, or and all other unique, and the other is unique in this metacalass. equivalent, is unique. metaclasses If the former, it makes little sense without specifying the mechanism that guarantees global uniqueness. If the latter, it should be clearly stated at Constraints, something like "The value of the attribute “Name” has to be unique in this metaclass."

page 4 of 6 ISO/IEC JTC1/SC32/WG2 N1783

Serial MB Clause No./ Paragraph/ Type Comment (justification for change) by the MB Proposed change by the MB Draft disposition Subclause Figure/ of No./ Annex Table/Note com- (e.g. 3.1) (e.g. Table ment 1) 026 JP 19 5.3.4 Refrence te "The set of entity types..."should be "The entity Not accepted – this form of types", because usually it is interpreted as there words is described in the Diagram entity_type_ can be many (*) sets of entity types. 19763 Modelling Guidelines. model_elem ent This comment is applicable to all the references whose maximum cardinality is *. 027 JP 20 Annex A Figure 2 ed It should be Figure A.1 to be consistent with Accepted ISO_IEC_Directives__Part_2. Similar comments are applicable to all figures and tables in Annex. 028 JP 21 Annex A te The following sentence is not true because Name Accepted - see resolution to and Context are defined in this standard and MDR JP17 does not have attributes named Name nor Context. 029 GB 04 Annex D ed The format of the examples is inconsistent with the Amend format of the examples to the Accepted format in other parts of 19763. 'object format' used in other parts of19763. 030 JP 22 C.2 ed It should be D.2 Examples Accepted Example tables 031 JP 23 C.2 te This Relational DBMS implementation does not See response to GB 04 (029) Example conform to this part, because this implementation tables does not support references of both directions. Examples should be the one that conforms to this part. 032 JP 24 Annex E ed It should be just Bibliography because Bibliography Accepted (informative) is Bibliography and is not Annex. Bibliography 033 JP 25 Annex E ed Each reference should be numbered with [ ]. Accepted (informative) Bibliography

page 5 of 6 ISO/IEC JTC1/SC32/WG2 N1783

Serial MB Clause No./ Paragraph/ Type Comment (justification for change) by the MB Proposed change by the MB Draft disposition Subclause Figure/ of No./ Annex Table/Note com- (e.g. 3.1) (e.g. Table ment 1) 034 JP 26 Annex E te "Bruce, T.A. (1992) Designing Quality Databases JP withdrew comment (informative) with IDEF1X Information Models. Dorset House Bibliography Federal Information" should be replaced by "Processing Standards Publication 184 Announcing the Standard for INTEGRATION DEFINITION FOR INFORMATION MODELING (IDEF1X), December 1993" 035 CA 04 All All Te If any further problems are discovered before or To be determined at the CRM as required. No further action at this time during the Comment Resolution Meeting, and a consensus can be reached on a solution, then they should be corrected.

page 6 of 6