a

Editor's draft disposition of comments CD2 19763-12 – Version 2 WG2 N1777

Serial / MB / Clause No./ Subclause No./ Annex (e.g. 3.1) / Paragraph/ Figure/ Table/Note (e.g. Table 1) / Type of com-ment / Comment (justification for change) by the MB / Proposed change by the MB / Draft disposition /
001 / CA 00 / All / - / Ge / Canada approves the draft with the following comments. / No further action at this time
002 / CA 01 / All / - / Ge / Since the new template allows for text to be referenced using line numbers, we generated a line numbered version of the text which is attached at the bottom of this document, and we have referenced those line numbers in our comments. / Canada asks that future ballot texts include line numbers so that all NBs can reference them. / No further action at this time
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 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. / Accepted
005 / JP 02 / 1 Scope / te / "These are often referred to as logical models." 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. / Accepted
006 / JP 03 / 1 Scope / te / "at the logical level" should be removed, because its meaning is not clear. / Accepted
007 / JP 04 / 1 Scope / te / "at the conceptual level" should be removed, because its meaning is not clear. / Accepted
008 / CA 03 / 4.2.3 / Note / Ed / NOTES are supposed to be in 9pt font. / Make the change here and to all other NOTES.
[Use the Note Style from the STD template.] / Accepted
009 / GB 01 / 4.2.6 / ed / The definition is too 'physical' / Amend to read: "component of a table (4.2.34) that is a collection of values all of the same defined data type (4.2.7)" / Accepted
010 / JP 05 / 4.2.8
described domain / te / It should be "non-enumerated domain", rather than "described domain", if it is necessary / Not accepted – the name “described domain” was chosen for consistency with ISO/IEC 11179-3:2013
011 / JP 06 / 4.2.8
described domain / te / Based on this definition, a continuous domain such as real number is not a described domain, since a set of all real number can be defined explicit ly. / Accepted – will use an adaption of the definition from ISO/IEC 11179-3:2013
012 / GB 02 / 4.2.9 / ed / The definition confuses real world and modelling concepts. / Amend to read: "'property of an 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)" / Accepted
013 / JP 07 / 4.2.17
enumerated domain / te / Based on this definition, a set of all real numbers can be enumerated domain, which is not discrete and strange in an intuitive sense of "enumerated".
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? / Accepted – will use an adaption of the definition from ISO/IEC 11179-3:2013
014 / JP 08 / 4.2.20
information model element / NOTE / te / Base on the definition of entity type(4.2.16), it cannot be an information model element, because it is not graphical nor textual representation. / Accepted – amended to read “element of an information model (4.2.19) that may be represented graphically and/or textually”
015 / GB 03 / 4.2.32 / ed / The definition should be compatible with that for column. / Amend to read: "sequence of values in a table (4.2.34), one for each column (4.2.6) of the table (4.2.34)" / Accepted
016 / JP 09 / 5 Structure of MFI Information model registration / ed / The abbreviated term "MFI Information model registration" needs to be defined. / Accepted
017 / JP 10 / 5.1 Overview of MFI Information model registration / ed / The meaning of "appropriate" in " This model is also appropriate for database structures that conform to the SQL Core specification." needs to be clarified. / This metamodel can be used for registering database structure specifications that conform to the SQL Core specification. / Accepted
018 / JP 11 / 5.1 Overview of MFI Information model registration / Figure1 / ed / The bottom raw of each rectangle should be removed, because no operations are specified. / Accepted
019 / JP 12 / After 5.1 Overview of MFI Information model registration / te / Sub clause"5.2 Association between MFI Information model registration and MFI Core and mapping " and a relevant figure should be inserted. / Accepted
020 / JP 13 / 5.2 Detail provided in each metaclass definition / te / This sub clause is not necessary, because almost everything except alternative names (Aliases) are specified in MFI 10.
As a standard, aliases are not necessary.
If aliases are specified, its conformance is not clear. To claim a conformance, is it necessary to support all aliases, or is it enough to support either a name or one of aliases ? / To be discussed
021 / JP 14 / 5.3.1 Attribute / Superclass
Model_Element / ed / "(defined in MFI Core and mapping)" should be "(from MFI Core and mapping)" to be consistent with other parts of MFI and MDR. / Accepted
022 / JP 15 / 5.3.1 Attribute / Subclasses / ed / It should be removed. / Accepted
023 / JP 16 / 5.3.1 Attribute / Aliases / te / Intuitively saying, a SQL column can be an attribute, but an attribute are not necessarily a SQL 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. / To be discussed – the purpose of including aliases was to provide the link between the metamodel and the various techniques, most of which use different terminology to that of the main names for the elements of the metamodel.
024 / JP 17 / 5.3.1 Attribute
and all other metaclasses / Attribute
Name / ed / It should not be in oblique style.. / To be discussed – in 5.2 the purpose of the italics was explained, but there is also the issue of whether these ‘inherited’ attributes should be included at all. Do they help to make the individual parts more easily understood?
025 / JP 18 / 5.3.1 Attribute
and all other metaclasses / Attribute
Name / te / The meaning of "unique" is unclear.
At least, there are two possibilities. One is globally unique, and the other is unique in this metacalass.
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." / See response to JP 17 (024)
026 / JP 19 / 5.3.4
Diagram / Refrence
entity_type_model_element / te / "The set of entity types..."should be "The entity types", because usually it is interpreted as there can be many (*) sets of entity types.
This comment is applicable to all the references whose maximum cardinality is *. / Not accepted – this form of words is described in the 19763 Modelling Guidelines.
027 / JP 20 / Annex A / Figure 2 / ed / It should be Figure A.1 to be consistent with ISO_IEC_Directives__Part_2.
Similar comments are applicable to all figures and tables in Annex. / Accepted
028 / JP 21 / Annex A / te / The following sentence is not true because Name and Context are defined in this standard and MDR does not have attributes named Name nor Context. / To be discussed
029 / GB 04 / Annex D / ed / The format of the examples is inconsistent with the format in other parts of 19763. / Amend format of the examples to the 'object format' used in other parts of19763. / Accepted
030 / JP 22 / C.2 Example tables / ed / It should be D.2 Examples / Accepted
031 / JP 23 / C.2 Example tables / te / This Relational DBMS implementation does not conform to this part, because this implementation does not support references of both directions.
Examples should be the one that conforms to this part. / See response to GB 04 (029)
032 / JP 24 / Annex E (informative)Bibliography / ed / It should be just Bibliography because Bibliography is Bibliography and is not Annex. / Accepted
033 / JP 25 / Annex E (informative)Bibliography / ed / Each reference should be numbered with [ ]. / Accepted
034 / JP 26 / Annex E (informative)Bibliography / te / "Bruce, T.A. (1992) Designing Quality Databases with IDEF1X Information Models. Dorset House Federal Information" should be replaced by
"Processing Standards Publication 184 Announcing the Standard for INTEGRATION DEFINITION FOR INFORMATION MODELING (IDEF1X), December 1993" / Publication added to Bibliography
035 / CA 04 / All / All / Te / If any further problems are discovered before or during the Comment Resolution Meeting, and a consensus can be reached on a solution, then they should be corrected. / To be determined at the CRM as required. / No further action at this time

page 5 of 5