SQL-99 is superseded by SQL:2003 (see comment on 3), which is mainly the same except that BIT and BIT VARYING data types are no longer included.
Proposed Solution: None proposed by source
"...and several examples are provided in Volume 2, Extensions, of the CWM Specification." This document is not referenced in either Clause 3 or the References Annex, and its role in this specification is not defined.
Nature of Problem:
A normative reference for OCL is required, because it is used in Clause 8 (and elsewhere)
Proposed Solution: None proposed by source
These tables gives data types from X/Open CLI SQL, which is not referenced in either Clause 3 or the References Annex but should not be used because they should be data types defined by SQL and the mappings defined by the current version (4) of JDBC.
Proposed Solution: None proposed by source
This annex should not be described as Normative, since all normative references should be in Clause 3. Some of the non-normative reference should be normative and be moved to Clause 3. All references should be to current specifications.
Proposed Solution: None proposed by source
The record and multidimensional arrays are aggregate datatypes and the common features of 11404 aggregates should be supported.
Proposed Solution:
Add features for 11404 aggregates.
CWM_1.0.dtd is missing the following element:
<!ELEMENT CWM:ModelElement.taggedValue (CWM:TaggedValue)*>
This element should be a child element of CWM:ModelElement and all elements
that correspond to subclasses of ModelElement.
Without this element, CWM_1.0.dtd does not conform to the CWM 1.0
Metamodel. According to the metamodel, any ModelElement (or its subclass)
can own TaggedValue through the TaggedElement aggregation.
An SQLParameter has no attribute. It should have some of the Column attribute: length, precision, scale and isNullable at minimum. This is valid for all the RDBMS.
The multidimensional arrays should support the notion of APL arrays, including rank and shape attributes.
Proposed Solution:
Add support for flat and nested N-dimensional arrays (not just arrays nested as arrays).
Nature of Problem:
It is inappropriate to use the name Procedure for referring to both procedures and functions (see 10.3.9). SQL uses the term routine for this purpose.
Proposed Solution: None proposed by source
Anyway, I think that there is a little error on the figure 6-6 chapter 6.2.4 of the v1.1 (wich is the figure 6, page 212 in the PDF, chapter 9.2.4 on the "old" document) : the Person has a "salary Column" instead of a "name column".
The description of referencingColumn implies that only a 'column' (i.e. an attribute) of a structured type can be of a type REF, whereas any column of a table can be so.
Proposed Solution: None proposed by source
SQL-92 and SQL-99 should not be used since they are no longer valid, and should NOT be described as ANSI documents
Proposed Solution: None proposed by source
The attribute XMLNamespace (also shown in Figure 13.1) is defined as a string, but it is an XML concept described by a specification separate from the referenced [XML], and quite distinct from the CWM concept of Namespace, and so should be referenced and described appropriately.
Proposed Solution: None proposed by source
This applies to CWM 1.1 (and also CWM 1.0).
Sun MDR user Vincent Lombart spotted that he was getting the same
association exported twice, which I tracked down to the following problem in
the metamodel.
There should be no explicit association between ClassifierMap and
TransformationMap: the diagram in the CWM spec just documents the fact that
the inherited ownedElement association is used to link these classes.
The CWM XMI file is produced by the Unisys Rose integration which explicitly
ignores such associations (signalled by '/' on the association ends - normal
derived associations have '/' on the association name). This is used in
several places e.g. in Relational model to show that Column and ColumnSet
are linked using the owner-feature association.
However in the ClassifierMap case there are also corresponding references
explicitly defined as pseudo-attributes on Classifier and TransformationMap
which has caused the references erroneously to be generated into the XMI
file.
On further investigation, the following inherited associations have
superfluous references:
XML:ElementType <-> XML:Schema
XML:ElementType <-> XML:Attribute
Transformation:TransformationMap <-> Transformation:ClasifierMap
Transformation:TransformationActivity <-> TransformationStep (in this case
the references are called 'step' and 'activity')
BusinessNomenclature:Taxonomy <-> Concept
BusinessNomenclature:Glossary <-> Term
BusinessNomenclature:BusinessDomain <-> Taxonomy (in this case one
reference is called just 'domain')
Proposed resolution:
Delete the above references/pseudo-attributes (with stereotype of
<<reference>> though this is hidden on the diagram).
The full set of 11404 aggregates (record, array, set, bag, sequence, etc.) should be supported.
Proposed Solution:
Support the full set of 11404 aggregates.
Nature of Problem:
The figure does not enclose emp_t in parenthesis (..) as shown correctly in the associated text.
Proposed Solution: None proposed by source
This normative annex appears to conflict with the intellectual property rights of ISO standards, and does not take account of the ISO requirement that all potential patents should be declared.
Proposed Solution: None proposed by source
CWM vol. 2 3.1 says "The concepts and ideas implicit in the definition of the COBOL language's DATA DIVISION were one of the earliest (if not the first) formalizations of the ubiquitous record model. A COBOL program contains much more than just record descriptions. However, because neither CWM nor UML attempt to describe programming languages directly, only the DATA DIVISION is described here. The model presented here is compliant to the COBOL 85 language standard [COBOL]."
UML Profile for EAI 14.1 says "The goal of this COBOL model is to capture the information that would be found in the Data Division." .
Both define COBOL Data Division metamodels with different levels of detail. We only need one COBOL Data Division metamodel.
Nature of Problem:
The referenced [SQL], the basis of this clause, is given as SQL:1999, which is no longer valid because it has been superseded by SQL:2003
Proposed Solution: None proposed by source
Nature of Problem:
This should make it clear that indexing is not part of SQL, and the use of SQLIndex in Figure 10.10 is entirely inappropriate.
Proposed Solution: None proposed by source
"XML Schema is an ongoing activity in the W3C. As future standards are adopted by the W3C on XML Schema, this package will be revised and extended accordingly." This document is not referenced in either Clause 3 or the References Annex, and the claimed revision has clearly not occurred.
Proposed Solution: None proposed by source
This annex should not be described as Normative, since it does not provide any requirement on the application of this standard as well as being incomplete and missing or being in conflict with the terminology of other normative references, such as SQL. The reference to RM-ODP is inappropriate, not being one of the listed sources.
Proposed Solution: None proposed by source
I think a parameter must have a multiplicity, because otherwise there can be never ever overgiven/returned an array to/from an behavioralfeature. I think this is not correct, i think maybe this is right for input parameters, but i think for output or return parameters there must be an multiplicity to model an behavioralfeauture correct.
Nature of Problem:
"A structured type is defined in terms of columns" - the SQL standard defines a structured type in terms of attributes and it is totally confusing to define it in terms of columns. A column can exist only within tables and can have constraints, which are not allowed for attributes of a structured type.
Proposed Solution: None proposed by source
The attributes length, precision and scale should not be present, because they are exactly the same as those for the related sqlSimpleType. What should be included are the methods that can be defined for distinct types.
Proposed Solution: None proposed by source
Nature of Problem:
A normative reference for ISO/IEC 9075:2003 Database language SQL is required, because it is the basis of Clause 10 (any previous edition has been superseded)
Proposed Solution: None proposed by source
Table: this currently reference a Table. However, most RDBMS support "instead of" triggers which can be applied to views. Table should be replaced by a reference to a NamedColumnSet
An essential feature of SQL structured types is that they have methods, whose properties should be recorded
Proposed Solution: None proposed by source
The expressions metamodel should have the kind of syntax associated the expression (e.g., is the expression C, APL, ksh, or something else, which all have significantly different parsing and syntax.
Proposed Solution:
Add the syntax type to the metamodel.
This annex is inappropriate in this standard, but if it remains it must be non-normative because it does not provide any requirement on the application of this standard.
Proposed Solution: None proposed by source
There is no requirement that the value "name" attribute of ModelElement correspond to the identifier (i.e., the string) of the model element.
Proposed Solution:
Add requirement that the "name" actually corresponds to the identifier of the model element.
The 11404 datatype generator features should be included via the expressions metamodel capability.
Proposed Solution:
Add datatype generators
Nature of Problem:
SQL should not be considered as an abbreviation for Structured Query Language
Proposed Solution: None proposed by source
Nature of Problem:
"Apart from this Foreword, the text of this International Standard is identical with that for the OMG specification for CWM 1.1 (formal/03-03-02)."
While true of the current document this cannot hold if changes are made to respond to NB comments.
Proposed Solution: None proposed by source
The specification does not identify the exact versions of MOF, UML and XMI that it refers to. Even if more than one version is applicable this needs to be made clear.
The datatype attributes don't incorporate the features of 11404 datatype (properties, characterizing operations, value spaces). There is no way to record this kind of standard datatyping information in CWM in a standard way.
Proposed Solution:
Add these features to the metamodel. Describe, in a standard way, how datatype characterizing operations would be recorded.
The attribute typeNumber is not an SQL concept, and since it is described as being assigned by the owning DBMS this makes it totally useless for any exchange between different DBMSs.
Proposed Solution: None proposed by source