Issue 7354: XML Schema of Deployment spec doesn't honour constraints present in model
Issue 7602: Type specification of MOF attributes
Issue 7603: Missing rule for generating type or element declarations
Issue 7604: Section 2.2.1, rule 6f
Issue 7605: no documented standard serializiation of MOF 1.4 as an XMI 2.0 schema
Issue 8321: opaque content
Issue 8437: Section: 8
Issue 8438: Section: 9
Issue 8795: Unclear serialization of derived data
Issue 8884: Impractical representation of structured datatypes
Issue 9074: Section: 4.4
Issue 9293: section 4.3.1 (Required XML Declarations),
Issue 9294: what, if anything, is normative in XMI 2.1
Issue 9295: section 4.5.3
Issue 9296: timestamp attribute
Issue 9396: Section 6.4.1 5j:Extension
Issue 9512: Urgent issue on XMI 2.1 -inconsistency between XMI metamodel and quoted XSD
Issue 9557: Section: 4.9.3
Issue 9624: Section 4.5.2
Issue 9625: Section 4.5.4
Issue 9626: 4.10.3 is an example from UML 1.4
Issue 9627: 4.10.3, line 4 of the example "Document 1"
Issue 9628: 6.5.3 2nd row of table
Issue 9629: 6.5 should be further clarified
Issue 9630: 2.3.1 the first bullet is very vague
Issue 9631: Figure 4.2
Issue 9632: logic for use of position attributes in 4.5.6 and 4.12.2 is not clear
Issue 9633: XSD fragment for difference elements in 4.5.6
Issue 9634: differences section 4.5 should refer to 4.12
Issue 9635: 2.3.3 is unclear as to what's needed for conformance
Issue 9636: 3.1 refers to 'XML Production of XML Schema'
Issue 9637: metamodel for XML Schema
Issue 9638: 4.3.3: in the following sentence the word 'lax' should be bold
Issue 9639: Section 4.3.1
Issue 9640: Section 4.3.3
Issue 9641: Section 4.4
Issue 9642: Section 4.5.1
Issue 9643: 4.6.1: should descrieb what importer is expected to do with label attribute
Issue 9644: 4.6.1, and elsewhere
Issue 9645: 4.6.1: uuid should refer to the use of URIs
Issue 9646: Section 4.5.3
Issue 9647: 4.5.3: the tag settings should include 'org.omg.xmi.attribute' = false
Issue 9648: end of 4.6.1
Issue 9649: Section 4.6.2
Issue 9650: Section 4.6.3
Issue 9651: type attribute should always be required in serialized elements.
Issue 9652: 4.8.1 has "the schema generator must choose ...
Issue 9653: frequent mentions of MOF attributes and references as opposed to properties
Issue 9654: Statement in section 4.8.1
Issue 9655: 4.8.1 The example should be made consistent
Issue 9656: XMI element is optional
Issue 9657: Statement in section 4.8.2
Issue 9658: Statement in section 4.8.4
Issue 9659: Section 4.8.4 editorial
Issue 9660: Section 4.8.4 issue
Issue 9661: 4.8.4
Issue 9662: Clarification in section 4.8.17
Issue 9663: Sections 4.8.l7, 6.5.3.1: syntax proposed is unusable
Issue 9664: Section 4.8.8
Issue 9665: xmi:type
Issue 9666: Statement in section 4.9
Issue 9667: issue with section 4.10.1
Issue 9668: 4.10.1 the following bullet is misleading
Issue 9669: Addition to section 4.10.1
Issue 9670: Section 4.10.1 last bullet
Issue 9671: Section 4.10.2.1
Issue 9672: Section 4.10.2.2
Issue 9673: Co.xml" is not a valid URI! I
Issue 9674: MOF2 does not have clustering
Issue 9675: Section 4.11, table 4.1
Issue 9676: 4.11, table 4.1: 'complex' is repeated in the list of values for contentTyp
Issue 9677: tag names should be in bold or full name used
Issue 9678: Section 4.11.2
Issue 9679: table 4.1 the href attribute
Issue 9680: last bullet of 4.11.2
Issue 9681: 4.11.3 is largely redundant with, and should be merged with, 4.11.5
Issue 9682: 4.11.6, 4.11.7
Issue 9683: 4.11.7 has: xmlns:xmi="http://www.omg.org/XMI" which is wrong
Issue 9684: 4.11.7 uses a type "GM_Curve£ which is not defined or described
Issue 9685: remove xsd:annotation elements
Issue 9686: attribute Mountain::elevation
Issue 9687: 4.11.7:example should make clear whether this is a CMOF or EMOF metamodel
Issue 9688: Section 4.11.7 issue
Issue 9689: Section 4.11.7 editorial
Issue 9690: 4.12.4 The example addition is not well-formed
Issue 9691: 4.12.4 the last XMI fragment
Issue 9692: 5.2 rule 1c
Issue 9693: 5.2 rule 1b and 1h
Issue 9694: 5.2 rule 6
Issue 9695: 5.2 rule 7: define 'Unreferenced Association' in MOF2 terms
Issue 9696: 5.2.2 refers to "XMI 2.0" and has wrong fixed declarations
Issue 9697: Section 7: the examples and rules use Attributes extensively not Properties
Issue 9698: Section 8
Issue 9699: Appendix A and references
Issue 10112: 4.4 XMI Schema and Document Structure
Issue 10426: Section: 4.11.5
Issue 10640: Section: 4.13.3
Issue 10658: 4.6.3 Version attribute
Issue 10659: timestamp
Issue 11000: Missing XSD files
Issue 11001: Fix on xmi:id attribute
Issue 11002: define a new XSD Type
Issue 11006: section 4.6.2 XMI Issue: Attribute "href" type
Issue 11511: Spec doesn't provide unified way to specify/represent link references
Issue 11512: Section: 4.8.5
Issue 11513: Section: 4.8.8
Issue 7354: XML Schema of Deployment spec doesn't honour constraints present in model (mof2xmi-rtf)
Click here for this issue's archive.
Source: Vanderbilt University (Mr. Krishnakumar Balasubramanian, kitty@dre.vanderbilt.edu)
Nature: Uncategorized Issue
Severity:
Summary:
Hi,
The Deployment & Configuration XML Schema defines a Property element like:
<xsd:complexType name="Property">
<xsd:choice minOccurs="0" maxOccurs="unbounded">
<xsd:element name="name" type="xsd:string" />
<xsd:element name="value" type="Deployment:Any" />
<xsd:element ref="xmi:Extension" />
</xsd:choice>
<xsd:attribute ref="xmi:id" use="optional" />
<xsd:attributeGroup ref="xmi:ObjectAttribs" />
</xsd:complexType>
<xsd:element name="Property" type="Deployment:Property" />
This allows for the following invalid Property file to be passed silently
by the XML Schema validator:
<?xml version="1.0" encoding="UTF-8" standalone="no" ?>
<Deployment:Property
xmlns:Deployment="http://www.omg.org/Deployment"
xmlns:xmi="http://www.omg.org/XMI"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://www.omg.org/Deployment Deployment.xsd">
<name>ORBSvcConf</name>
<value>
<type>
<kind>tk_string</kind>
</type>
<value>
<string>Foo</string>
</value>
</value>
<value>
<type>
<kind>tk_short</kind>
</type>
<value>
<long>123</long>
</value>
</value>
</Deployment:Property>
The model in 6.10.8 has a containment association with a cardinality one
for value. The schema generated from that model doesn't match the semantics
in the model. This is just an example. There are a lot of elements where
the semantics imposed by the schema are different from what is described in
the model. I am curious as to why this is allowed. It can be easily fixed
by changing the schema to:
<xsd:complexType name="Property">
<xsd:sequence minOccurs="0" maxOccurs="1">
<xsd:element name="name" type="xsd:string" />
<xsd:element name="value" type="Deployment:Any" />
<xsd:element ref="xmi:Extension" minOccurs="0" />
</xsd:sequence>
<xsd:attribute ref="xmi:id" use="optional" />
<xsd:attributeGroup ref="xmi:ObjectAttribs" />
</xsd:complexType>
<xsd:element name="Property" type="Deployment:Property" />
During the meetings and telephone conferences of the RTF it has been agreed that this issue is to be transferred to the MOF2XMI RTF. The source of this problem (issue #5950) has already been submitted to the MOF2XMI FTF. They acknowledged the problem but decided to close it without change since it would be too much work for them. Now a related issue is popping up again.
This issue is preventing me from implementing an XMI 2.0 Schema generator for a MOF 1.4 metamodeling environment. The specification contradicts itself regarding the type specification of MOF Attributes. >From section 1.8.4: “The XML element corresponding to the attribute is declared in the content of the complexType corresponding to the class that owns the attribute. The type specification is either an XML schema data type, an enumeration data type, or a class from the metamodel.” Then, in section 2.2.1, rule 4d: “The type is “xsd:string” for simple attributes, the name of an enumeration for enumerated attributes, or part of the value of the org.omg.xmi.schemaType tag, if present.” I have no idea what the specification means by “simple attribute” (the phrase appears just that one time in the entire document), but the two statements above are clearly out of sync and confusing. Also, the type of an attribute might be something other than a metamodel Class, PrimitiveType, or EnumerationType in MOF 1.4: it might for example be a CollectionType or an AliasType. Rules are provided for serializing these other DataType subtypes as Classes, but they themselves are not metamodel Classes.
This problem is preventing me from implementing an XMI 2.0 Schema generator for a MOF 1.4 metamodeling environment. XMI 2.0 Schema: There is no rule for generating type or element declarations for Classifiers nested inside of a Class. MOF Classes don’t get corresponding XMI namespaces. XMI 2.0 seems to ignore the fact that MOF Classes define Namespaces. It is completely valid in MOF to have a Class A which contains an Attribute B and a Class C, where Class C serves as the type of Attribute B. You could also replace ‘Class C’ with any DataType subtype – say ‘CollectionType C’. However, there is no rule for declaring types or elements for nested Classifiers, so the specification does not say how to declare the type of serialized Attribute B. Even if there were a rule for type and element declarations for Classifiers nested within a Class, the nsPrefix and nsURI tags only apply to Packages. Since Classes don’t define XMI namespaces, any nested Classifiers are going to suffer from name collision. If you look at the Eclipse Modeling Framework, you can see how implementers of MDA standards have gotten around this. The MOF-based EMF metamodeling language (ECORE) simply doesn't allow nested Classifiers or DataType subtypes other than EnumerationTypes and PrimitiveTypes. XMI 2.0 is supposed to be designed with MOF 1.4 in mind, so I shouldn't have to limit my metamodeling environment to a subset of the expressive power of MOF just for the purpose of XMI metamodel interchange.
This problem is preventing me from implementing an XMI 2.0 Schema generator for a MOF 1.4 metamodeling environment. In Section 2.2.1, rule 6f, nested Package elements contained within the complexType definitions of their encapsulating Packages refer to global Package element definitions using the namespace-qualified name of the nested Package. But global Package elements are never associated with their namespace-qualified names, so the reference cannot be resolved. Rule 6a, which defines namespace-qualified Package names, only gets used a single time during schema generation: in rule 6f. This makes it impossible to correctly generate a schema from a metamodel which includes nested Packages.
There is no documented standard serializiation of MOF 1.4 as an XMI 2.0 schema. OMG has published a document for MOF 1.3 as an XMI 2.0 document and MOF 1.4 and an XMI 1.2 DTD, but not MOF 1.4 as an XMI 2.0 schema. This is despite the fact that XMI 2.0 was designed around MOF 1.4. As far as I know, OMG has not released a single full XMI 2.0 schema example. Do any exist?
Inside UML and SysML, there are cases where opaque content occurs as strings. In particular, in the body of comments and constraint expressions. In SysML it is suggested that MathML be used for parametric constraints, similarly Z can be used instead of OCL. MathML is an XML language, and Z may be interchanged using ZedML, an XML language. In comments, it would be nice to allow XHTML for formatting rich text. At the moment, these are all possible by escaping the XML in the opaque string which ends up in an attribute value: <!DOCTYPE xmi:XMI SYSTEM "http://schema.omg.org/spec/XMI/2.1" [ <!ENTITY math "http://www.w3.org/1998/Math/MathML"> <!ENTITY modelica "http://www.modelica.org/documents/ModelicaSpec21.pdf">]> <xmi:XMI xmlns:UML="http://schema.omg.org/spec/UML/1.4" xmlns:SysML="http://schema.omg.org/spec/SysML/0.9" xmlns:xmi="http://schema.omg.org/spec/XMI/2.1"> <Documentation> <shortDescription>Some queries on parametric constraints in SysML.</shortDescription> </Documentation> <UML:Model name="BaseLibrary" xmi:id="z0"> <ownedElement xmi:type="UML:Package" xmi:label="BasicPhysics" xmi:id="z1"> <ownedElement xmi:type="SysML:ParamConstraint" xmi:label="NewtonsSecondLawOfMotion"> <ownedElement xmi:type="SysML:Parameter" xmi:label="F" type="Force"/> <ownedElement xmi:type="SysML:Parameter" xmi:label="m" type="Mass"/> <ownedElement xmi:type="SysML:Parameter" xmi:label="a" type="Acceleration"/> <ownedElement xmi:type="UML:Constraint" constrainedElement"> <!-- SysML suggests MathML as a constraint language, but the body of a constraint is defined as a string, so XMI maps it to a xsd:string. This means XML literals such as MathML have to be escaped. This complicates general XML tool based queries of the model. --> <specification xmi:type="UML:OpaqueExpression" language="&math;" body=" <math xmlns="&math;"e;> <apply> <eq/> <ci>F</ci> <apply> <times/> <ci>m</ci> <ci>a</ci> </apply> </apply> </math> </math> "/> </specification> <!-- Alternatively is it assumed that there will be a mapping of the abstract syntax of the expression language to non-opaque expressions? Either way, it's harder than it needs to be to embed MathML into the Model. --> <specification xmi:type="UML:Expression" symbol="&math;#eq"> <operand xmi:type="UML:Expression" symbol="F"/> <operand xmi:type="UML:Expression" symbol="&math;#times"> <operand xmi:type="UML:Expression" symbol="m"/> <operand xmi:type="UML:Expression" symbol="a"/> </operand> </specification> <!-- In UML2 specification is multiplicity [0..1]; is there no mechanism for specifications in multiple languages? You /could/ use an 'one-of-n' Expression on these, but that sort of implies the expressions may be evaluated, rather than 'choose the one you can evaluate in your context', which is what you can do with XPath and the language attribute. Should you define multiple constraints in such cases, even though it's the same constraint, expressed in a manner to be processed by different tools? --> <specification xmi:type="UML:OpaqueExpression" language="&modelica;" body="F = m * a"/> </ownedElement> </ownedElement> </ownedElement> </UML:Model> </xmi:XMI> If you are post-processing the XMI using standard XML technologies (XPath, XSLT, XQuery), it is far better to have XML as nested elements rather than escaped strings- even using XMI's option for having a <body> element will still require the content to be xsd:string. Can the mapping be changed so that opaque content is string or any element() from a different namespace, allowing MathML and ZedML to be used as opaque constraints and XHTML etc. as comments without breaking the way XML is intended to work? The data value is opaque anyway, and converting XML to escaped XML inside XML is reduces generic tool support and adds no value. This may need to effect the UML core too- changing the type of the opaque string to OpaqueString rather than string; alternatively a tag 'org.omg.xmi.parsedContent' could be added to indicate the string (assumed to be a valid XML document fragement) is serialised as parsed XML content rather than unparsed content. It is understood that Extension elements allow xsd:any content, but in these cases the structured content is the actual value of the attribute as an opaque string, rather than an extension to the model - the body of the contstraint is the MathML, just as much as it would be if it were OCL, rather than the MathML being additional, vendor specific data. Pete
The document MOF 2.0 XMI Mapping (ptc/04-06-11) contains some (typographical) errors in the EBNF for XML Schema Production (Chapter 8). The proposed corrections are listed below: 1g. XMIFixedAttribs ::= ( "<xsd:attribute ref=’xmi:id’" "use=’optional’>" | "<xsd:attribute name=’" //Id attrib name// "’" "type=’xsd:ID’ use=’optional’>") "<xsd:attributeGroup ref=’xmi:ObjectAttribs’/>" 4. ClassTypeDef ::= "<xsd:complexType name=’" //Name of Class// "’" ("mixed=’true’")? ">" ( "<xsd:complexContent>" "<xsd:extension base=’" 4a:ClassTypeName "’")? ("<xsd:choice minOccurs=’0’ maxOccurs=’unbounded’>" | "<xsd:sequence>")? ( 4b:ClassContents | "<xsd:any minOccurs=’0’ maxOccurs=’unbounded’ processContents=’" // ProcessContents Value // "’/>")? ("</xsd:choice>" | "</xsd:sequence>")? 4g:ClassAttListItems ( "</xsd:extension>" "</xsd:complexContent>" )? "</xsd:complexType>" 7a. AssnElmtName ::= 1h:Namespace //Name of association// 8. EnumSchema ::= "<xsd:simpleType name=’" 8a:EnumTypeName "’>" "<xsd:restriction base=’xsd:string’>" 8c:EnumLiterals "</xsd:restriction>" "</xsd:simpleType>" Futhermore, production rule 4i contains a reference to QName. This is neither a rule nor a terminal/placeholder. Please clarify. Regards, Mick Baggen Principal Consultant Technolution
The document MOF 2.0 XMI Mapping (ptc/04-06-11) contains some (typographical) errors in the EBNF for XML Document Production (Chapter 9). The proposed corrections are listed below: 1a:XMI ::= "<" 1b:XMINamespace "XMI" 1c:StartAttribs ">" ( 2a:XMIObjectElement)* ( 3:Extension )* "</" 1b:XMINamespace "XMI>" 1b:XMINamespace ::= (1h:NsName ":") ? 1e:Namespaces ::= 1f:XMINamespaceDecl ? ( "xmlns:" 1h:NsName "=’" 1i:NsURI "’" )* 1f:XMINamespaceDecl ::= "xmlns=’http://www.omg.org/XMI’" | "xmlns:" 1h:NsName "=’http://www.omg.org/XMI’" 1g:Namespace ::= ( 1h:NsName ":" )? 2h:FeatureAttrib ::= 2i:XMIValueAttribute | 2j:XMIReferenceAttribute 3:Extension ::= "<" 1b:XMINamespace "extension" (" extender=’" // extender // "’")? (" extenderID=’" // extenderID // "’")? ">" // Extension elements // "</" 1b:XMINamespace "extension>" Furthermore, the notation for placeholders throughout the document is inconsistent. Chapter 8 uses text in enclosed double slashes (//placeholder//), whereas in Chapter 9 (without any introduction) placeholders are shown in italics. Please clarify or correct.
Section 9.5.3 on p64 has a bullet: "Addition to Rule 1 for the EMOF package: in some well-defined cases, derived information has a more compact form than (and should be serialized instead of) the information it is derived from. Examples from the UML2 superstructure are multiplicity and generalization." and on p65 has the following bullet: "No special serialization rules need to be defined for subsetted Properties. Following EMOF rule 1, when one of the subsetted or subsetting Properties is derived, it is not serialized by default. Properties that are not derived are serialized." However the referenced EMOF rule 1 was removed from the XMI submission prior to adoption (it is there in ad/02-12-07): it was in (what is now) section 9.5.2 as the first bullet under the table and stated: "• Derived information is not serialized." So as things stand the specification does not hang together, since there are references to a non-existent rule. And subsetted properties would always be serialized (unless a tag is used to override) In general it does not make sense to serialize derived information since it bloats the file, is redundant, and in the bulk of cases derived Properties are readOnly so cannot be used on import anyway. So the rule from the original submission seems to be make sense - especially as there is the ability to override the default. Not having the rule means that all the derived Properties in UML (for example) would have to be explicitly tagged with serialize=false. With respect to the 'well defined cases' where derived is serialized, it should be made clear that it is up to the metamodel definition (e.g. UML) to do the efinition of which derived properties are to be serialized. It is misleading to refer to specifiy examples which may or may not be correct (at time of writing UML does not do this). Proposed resolution ---------------------------- 1. Reinstate the missing rule by adding a new first bullet in section 9.5.2: "• Derived information is not serialized." 2. In section 9.5.2 replace the bullet: "Addition to Rule 1 for the EMOF package: in some well-defined cases, derived information has a more compact form than (and should be serialized instead of) the information it is derived from. Examples from the UML2 superstructure are multiplicity and generalization." With "Additional to the first bullet in rules for the EMOF package: for some metamodels, it may be desirable to serialize particular derived Properties, since the derived form has a more compact form than (and should be serialized instead of) the information it is derived from. In this case the default behavior can be overridden by setting the serialize tag to 'true' for the derived property and to 'false' for the base Property (or Properties). However this step should be taken with caution since it also requires the derived property to be writeable (isReadOnly=false) and, to be able to import the information, it must be possible to reverse-derive the base information from the derived form." 3. Section 2.9.8, replace "The serialization tag is provided to optionally suppress derived data." with: "The serialize tag is provided to optionally include derived data." 4. Section 2.12.1, in the entry for serialize, replace 'boolean' by 'string' in column 2, 'true' by' non-derived' in column 3 and in column 4 replace: "If false, suppresses serialization of the MOF construct. Typically applied to derived features." with: "If 'non-derived' then the MOF construct is serialized unless it is derived. 'true' forces the construct to be serilized regardless of wheher it is derived; and 'false' suppresses the it regardless." 5. Rule 2h on page 61. Replace: "You must not serialize an attribute or reference at all if the value of the org.omg.xmi.serialize tag is "false"." With: "You must not serialize an attribute or reference at all if the value of the org.omg.xmi.serialize tag is "false"; or the value of that tag is "non-derived" and the attribute or reference has isDerived="true"."
Section 7.8.7 and example in 9.5.3.1 state that structured datatypes should be represented in a 'flattened' structure as a sequence of strings separated by commas in an XML attribute. Though the rules for the representation are very informally specified through examples only, the normative text saying only: "The values of the Properties are serialized as a single string separated (by default) by commas. The default separator can be overridden by the XMI valueSeparator tag." This is impractical for several reasons: - it does not allow string values that may contain quotes or commas: although the separator may be changed at the attribute level this is not very helpful and there is no means of escaping the separator character; - it breaks other XMI rules (for example a multivalued property is forced to use the XML element form and not the XML attribute form); - it breaks principles of composability - the same value will appear quite differently if nested in a structure than if it appeared as a property value in its own right; - it is against guidelines for designing XML structures and is inconvenient to process using most XML technologies. Indeed it is against the whole principle of XML which is for self-identifying structures and is very fragile to metamodel changes; - it fails if any of the properties of the structure have multiplicity of other than 1..1. For example for a DataType PersonName with properties: title [0..1] forenames[1..*] lastName[1] suffixes[0..*] it would be impossible to parse the string e.g. "Duke, John, William, London, Squire"; - it's trying to optimize the wrong thing: human readability rather than computer processability; - it introduces an arbitrary inconsistency with XMI 2.0; Proposed change Retain the current flattened XMI 2.1 format only as a special option triggered using a new tag org.omg.xmi.flattenStructuredDataTypes (which should default to "false"). This should be restricted in use only for structures whose properties (including nested properties) all have multiplicity of 1..1. The default should be to use the XMI 2.0 format for structures: the text should be taken from section 3.5.1 of the XMI 2.0 spec formal/05-05-01.
In section 4.4, the XML header is incorrect. Instead of <? XML version=”1.0” ?> it should be <?xml version="1.0"?> and instead of <? XML version=”1.0” ENCODING=”UCS-2” ?> it should be <?xml version="1.0" encoding="ISO-10646-UCS-2"?> Rationale: The W3C XML recommendation specifies in production 23, that there is no space between <? and XML, and that XML is to be written in lower case. In production 80, encoding is specified as lower case. Section 4.3.3 specifies that ISO-10646-UCS-2 should be used to denote UCS-2. If possible, QUOTATION MARK should be used in the PDF file for the quoting the parameter values.
In the referenced document, section 4.3.1 (Required XML Declarations), the text: Some of these XML elements contain metadata about the metadata to be transferred, for example, the identity of the model associated with the metadata, ..., whether the metadata has been verified, etc. This text is not aligned with either the model classes defined in section 4.5.2 (XMI Model Classes) or the implicit XMI XSD defined in section 4.5.5 (Documentation). The reason for this is that information about the model, metamodel, verification, etc, appears to have been dropped from earlier versions of XMI. My preference would be to restore it (to the extent that it makes sense in the UML2/MOF2 world), but at the least the sections should be aligned.
In the conformance section of 05-09-01, all mandatory conformance points are given in terms of the rules (for schema and document production) defined in the specification. Are these rules the extent of the normative part of the specification? In particular, there is a reference in 05-09-01 (section 2.3.3) to "Use of the normative XML Schema model by instantiation,…" It is unclear what "XML Schema model" refers to. Should there not be a reference to (what I presume to be) the XML Schema standard(s), thush leaving the sum total of the normative nature of the spec the rule sets mentioned above? Or, if the intent is to name the XMI Schema Infoset model in Chapter 8 as normative, why isn't the proper name used, along with a section reference? Finally, there are fragments of an XSD file for XMI in section 4. Why is there no XMI.XSD file disseminated by the OMG? I suppose one could put together such a file by copying the text from the spec, but why bother?
In section 4.5.3, a paragraph is dedicated to describing a problem with the xmi version: Since the XMI model is an instance of MOF, it can be serialized using the same rules as any other MOF model, with one exception. Using the default serialization rules would result in the XMI version attribute appearing twice in XMI elements: once directly from the XMI version attribute, and once through the inclusion of the ObjectAttribs group. Therefore, the version attribute that belongs to the ObjectAttribs attribute group must be excluded from the XMI type declaration. See Section 6.4.1, “Overall Document Structure,” on page 58” for details on how the XMI class is serialized. However, in section 4.5.1, it was stated: In addition, there are attribute declarations and attributeGroup declarations that must be imported. These include the id attribute, and the IdentityAttribs, LinkAttribs, and ObjectAttribs attribute groups. These constructs are not defined in the XMI model. These two statements are inconsistent.
As late as a draft of XMI 1.3 that I have, there were two attributes of the XMI element, verified and timestamp which disappeared from the XMI element in XMI 2.0 and were not restored in XMI 2.1. I'm not sure how useful the verified attribute was, but I have always found the timestamp attribute to be extremely useful in determining the provenance of XMI documents and have set it on my XMI 1.1 exports (most notably the Unisys Rose XMI Addin). I find it very annoying that it is missing from XMI 2.1.
I have a question regarding XMI 2.1 specification, document formal/05-09-01
I'm not certain that you are the right people to answer, but I'll try.
Here it is.
Section 6.4.1. Overall document structure (in EBNF rules production)
refers to 5j:Extension, however this element is never mentioned in the document. It was defined in XMI 2.0 formal/05-05-01.
Here is the fragment:
1a:XMI ::= "<" 1b:XMINamespace .....
...
( 5j:Extension )*
...
Is this an error in the document, or should we use the 5j:Extension from XMI 2.0 ?
This references formal/05-09-01. It is urgent since it represents inconsistencies in the specification - a resolution of which is required in order to avoid randomly inconsistent and non-interoperable implementations. This version of the specification includes a metamodel for the XMI element, in section 4.5, so that its serialization can use the same metamodel-driven rules as any other metamodel element. In fact section 4.5.1 states "When the XMI model is generated as an XML Schema following the XMI schema production rules, the result is a set of XML element and attribute declarations. ". However section 5.2.2 contains 'Fixed Schema Declarations' that are inconsistent with this, and in fact seem to be carried over unchanged from XMI 2.0 (as indicated by the fixed version number: <xsd:attribute name="version" type="xsd:string" use="optional" fixed="2.0" form="qualified"/> In addition to the wrong version number the XMI element in 5.2.2 is missing the metamodel properties XMI::documentation, XMI:difference and XMI::extension. Also the fact that only XML elements are used should be reflected. Proposed resolution Fix the specification to match the XMI metamodel. This should also have XMI tags added to reflect the serialization of the XMI properties as elements only. The missing XMI.xsd file should be produced as a separate file and made available as both an OMG document and at the correct URL. The fragments of this XSD that appear in the document need to be changed.
The example shows two elements with tags ownedElement which are of types UML:Class and UML:Datatype. Since XML presumes that the tag defines the type it is difficult to see how ownedElement could be defined using XSD. I suggest allowing something like the following as an option: <UML:Model name="model1" xmi:id="id1"> <UML:Class xmi:role="ownedElement" name="class1" xmi:id="id2"> <UML:Attribute xmi:role="feature" name="attribute1" type="type1"/> </UML:Class> <UML:Datatype xmi:role="ownedElement" name="Integer" xmi:id="type1"/> </UML:Model> This would eliminate the need to define an element in XSD, and the need to wait for attributes to determine type when using SAX. And, since an XSL style sheet to convert between to two forms is a trivial exercise, impact should be minimal.
The String datatype is the data type for strings in the MOF model with XML Schema data type of "http://www.w3.org/2001/ XMLSchema#string." The Integer datatype is the data type for integers in the MOF model with XML Schema data type of "http://www.w3.org/2001/XMLSchema#integer." This should instead reference the PrimitiveTypes package used by MOF Core and UML Infra.
Section 4.5.4 has: "The extenderID is an optional internal ID from the extending tool. " This should be more specific: it should state that the id must allow the element to be uniquely located within that tool.
4.10.3 is an example from UML 1.4: this should be updated for UML 2.1. UML 1.4 is not a valid example since it is not a MOF 2 metamodel - so outside the scope of the XMI 2.1 rules. Likewise 4.9.3, 4.12.4.
4.10.3, line 4 of the example "Document 1" has: <constrainedElement xmi:idref="idO1"/> This is not valid and requires a xmi:type attribute. Likewise for other such elements in the example.
6.5.3 2nd row of table starts "As Association": this should be "An Association",
6.5 should be further clarified to make clear that these rules, also apply to *instances* of Abstractions, EMOF and CMOF packages e.g. how to serialize instances of a CMOF metamodel such as UML - that is how to serialize UML models. In general 6.5 should be better integrated with 6.4: as it stands the rules for EMOF and CMOF seem an afterthought, whereas 6.4 is all about serializing EMOF or CMOF models.
2.3.1 the first bullet is very vague for a compliance point and requires rewording: The first sentence has no verb. The second sentence is too vague with respect to 'designated extension areas' and 'the nature of the extension' and 'where applicable' and 'where appropriate'. The second bullet does not say *how* the differences section is to be processed (and the differences section itself does not give that detail).
In Figure 4.2 the XMI model references Object (from MOF) which should be MOF::Element
The logic for use of position attributes in 4.5.6 and 4.12.2 is not clear. For example it states "The default, -1, indicates to add the replacing elements at the end of the target element." however the model allows *many* target elements which may be distributed throughout - so the explanation does not make sense. Furthermore it's not clear what the effect of a positive value would be e.g. "5". This applies to Add as well as Replace. Even the text 'at the end of the target element' is not precise. I suspect the intent is to allow elements to be added in the sequence of others owned by a containing element but this is not at all clear. Position is for some reason defined as xsd:string in the XSD fragment - whereas it is declared as Integer in the XMI model. Also the purpose/effect of nested Difference elements is not explained.
The XSD fragment for difference elements in 4.5.6 uses XSD:IDREFS for 'target' which does not allow reference to external elements using href. The intention is clearly to allow external refercnes: section 4.5.6 starts "The Add class represents an addition to a target set of objects in this document or other documents." And 4.12.4 has an example (which is not valid acordign to the XSD fragment).
The differencs section 4.5 should refer to 4.12 for how the differences are to be processed
2.3.3 is unclear as to what's needed for conformance: the following seems t allow any/all of the usages listed. "Use of the normative XML Schema model by instantiation, code generation, invocation, or serialization". Furthermore the XMI specification says nothing about 'code generation' or 'invocation'. Finally the compliance point uses the term 'XML Schema Model' yet section 8 uses "XML Schema Infoset Model".
3.1 refers to 'XML Production of XML Schema' which was the name of an RFP/submission but not a formal specification
Given that the XMI spec contains a metamodel for XML Schema it would be possible to express the Schema production rules using QVT as a transformation from the MOF metamodel to the XSD metamodel. This would create a more rigorous specification that could be automated
4.3.3: in the following sentence the word 'lax' should be bold. "The processContents attribute is lax,"
4.3.1 states "Some of these XML elements contain metadata about the metadata to be transferred, for example, the identity of the model associated with the metadata, the tool that generated the metadata, whether the metadata has been verified, etc." However the XMI spec has nothing about verification - so this last clause should be deleted.
4.3.3 includes "One use of the extension mechanism might be to associate display information for a particular tool with the model class represented by the XML element. Another use might be to transmit data that represents extensions to a model." This is no longer a good example since the Diagram Interchange standard provides the proper means to represent dislay information.
4.4 has "An XML document containing only XMI information will have XMI as the root element of the document." And 4.5.3 has first sentence "The top level XML element for XMI documents containing only XMI data is the XMI element." These are not consistent with the rest of the document and practice: for example later in 4.5.3 has: "The XMI element need not be the root element of an XML document; you can include it inside any XML element that was not serialized according to this specification. If a document contains only XMI information, the XMI element is typically not present when there is only a single top-level object."
4.5.1: should state that there is a standard file XMI.xsd (with an OMG document number) that contains the elements for the XMI model and the elements referred to here: "In addition, there are attribute declarations and attributeGroup declarations that must be imported."
.6.1: should descrieb what an importer is expected to do with the label attribute. The label attribute should be n the XMI model as should id and uuid.
21) 4.6.1, and elsewhere: should relate the 'id' and uuid' attributes to the 'Property::isId' and Package::id properties in the MOF2 Core spec. These are mentioned nowhere in the XMI spec. In fact it seems that the org.omg.xmi.idProperty tag is redundant with Property::isId.
4.6.1: uuid should refer to the use of URIs, as defined in MOF2 Core, rather than the DCE form of identifier. The DCE standard is no longer relevant in Appendix A.
4.5.3 contains the sentence "The serialization of the XMI element is special--it is defined by the XML Document Production rules in Chapter 8." which is wrong and should be deleted: for exampel it is inconsistent with the previous paragraph in 4.5.3 "Since the XMI model is an instance of MOF, it can be serialized using the same rules as any other MOF model, with one exception."
4.5.3: the tag settings should include 'org.omg.xmi.attribute' = false (to match the XSD fragments included). The Tags should be in the XMI file for the XMI metamodel
The end of 4.6.1 has "The MOF refID() is often used as the uuid in XMI implementations." MOF2 does not have this operation: instead the URI capabilities of MOF 2 Core and Facility specs should be referenced.
4.6.2 contains "The id attribute value can be specified using a special URI form for XPointers defined in the XLink and XPointer recommendations." These specs need to be included as Normative references. More detail and examples should be given as to how the generic XML capabilities are applied to XMI and the id/uuid/URI.
4.6.3 contains "The version attribute is required only when the XMI version cannot be determined from a parent XML element:" however this is inconsistent with the earlier statement that the version attribute is not required at all since the XMI nsURI determines the version.
In order to allow XMI to be resilient to extensions then it is not possible to guarantee the target type of any property. Therefore the type attribute should always be required in serialized elements. Proposed resolution: a) 4.6.4 replace "The type attribute is used to specify the type of object being serialized, when the type is not known from the model. This can occur if the type of a reference has subclasses, for instance" with "The type attribute is used to specify the type of object being serialized. Although in some cases the type is known from the model, this attribute is required to allow for the target type to be extended with further subclasses." b) 4.6.4 replace <xsd:attribute name="type" type="xsd:QName" use="optional" form="qualified"/> with <xsd:attribute name="type" type="xsd:QName" form="qualified"/>
4.8.1 has "the schema generator must choose one or more namespace URIs that uniquely identify the XML namespaces in the model." The reference to 'choose' is incorrect - the URI is detrmined by the mandatory org.omg.xmi.nsURI tag.
There are still frequent mentions of MOF attributes and references as opposed to properties. For example 4.8.1 has several mentions such as "model attributes and references is the short name of the attribute or reference." And 4.8.5 is actually titled 'Reference representation' (4.8.4 should be "DataType-typed Properties' and 4.8.5 should be 'Class-typed Properties"). The text needs to be qualified also - for example "For multi-valued Properties, no XML attributes are declared; each value is encoded as an XML element." is wrong if the property is Class-typed. 4.8.6: Should use "Class-typed Property" instead of "association roles". 4.8.8: "AssociationEnds with references" should be "Class-typed properties" 4.11.4: "You may choose features (MOF attribute or reference)" 4.11.4: "The feature is a multi-valued attribute, or * The feature is an attribute whose type is not a simple data type." (note that in the last clause 'simple data type' is not a well-defined term). 4.11.5: "and for attributes and association ends belonging to the class. For example, the element tag applies to attributes and association ends. If the element tag is set to true for a class, the class itself is not affected, but each attribute and association end belonging to the class is treated as if the element tag were set to true for all of them." 5.2 rule 2 has "Associations without References," and rule 3 has "based on the attributes and references". Rule 4 contains numerous rules for Attributes and References. 6.4.2 likewise
4.8.1 states "each tag in XML has its own namespace." which is not technically correct - 'naming context' would be btter than 'namespace'
4.8.1 The example should be made consistent with the actual URI and prefix for UML2. And the structure ('feature' and Attribute are wrong)
4.8.1 Includes: "The logical URI is placed in the namespace declaration of the XMI element in XML documents that contain instances of the model." However the XMI element is optional.
4.8.2 states "By default, XMI produces schemas that ignore multiplicities also." This should refer to "XMI 2".
4.8.4 states "then by default XML attributes are declared for them as well as XML elements. The reasons for this encoding choice are several, including: the values to be exchanged may be very large values and unsuitable for XML 18 MOF 2.0/XMI Mapping Specification, v2.1 attributes". This reads as if the reasons are for the XML attribute encoding choice (which it is not). Should say "The reasons for the XML element coding choice...".
4.8.4 has "For properties whose types are primitive types (for example, string)". The last word should be String (capital S).
4.8.4 has "where enumName is the name of the enumeration type, and v1 and v2 are the enumeration literals." This should be "where enumName is the name of the Enumeration, and v1 and v2 are the names of the EnumerationLiterals."
4.8.4 has: "For properties with default values, the default value should be the XML string representation to be placed in the schema. Default values for properties should be specified in schemas with care since XML allows the processor reading the document the option of not processing a schema as an optional optimization. When tools skip processing the schema, they do not obtain the default value of XML attributes. Instead, they would have to know the default value from understanding the model." This largely dates from MOF 1.x which did not have default values (but XMI allowed them to be specified in the XSD). Therefore the 'with care' proviso no longer applies and so the text should be: "For Properties with default values, the XML string representation is placed in the schema." In fact this makes the tag org.omg.defaultValue redundant (and potewntially in conflict with the metanmodel) - the tag should be removed from the spec (e.g. in table 4.1).
4.8.l7 should make clear that it does not apply to Enumerations and Primitives (which are subclasses of DataType). In this section datatype should be properly written DataType. The sentence "In the instance document, the value of the datatype appears as character content." is not generally correct as shown by the example of Point in this section.
4.8.l7, 6.5.3.1: the syntax proposed for stringifying structured datatypes is ambiguous and not usable. It's ambiguous since there is no way to tell when the list of values for one multivalued property ends and another starts (the examples all have single-valued properties). If we have a DataType TwoShapes with properties s1: Point[2..*] and s2: Point[2..*] then with the proposed serialization a value such as (1,2,3,4,5,6,7,8,9,10,11,12) is not separable into s1 and s2 values.
Furthermore it ignores the names of the properties. And has no value for EMOF as claimed: a more natural representation of a structured DataType would be as a class in EMOF. Therefore there should at least be the option to serialize the values using a class-like approach. In fact section 4.14 does state that "MOF complex data types are treated as MOF classes with each field treated as a MOF attribute with a primitive type mapped to XML schema." So for the Point example this would be:
<TwoPointsOnAGraph>
<point1 x="0" y="0"/>
<point1 x="1" y="5"/>
</TwoPointsOnAGraph>
and for the Area example would be:
<aRectangle>
<area>
<point1 x="0" y="5"/>
<point1 x="4" y="0"/>
</area>
</aRectangle>
4.8.8 Should say "more control to the metamodeler" rather than "to the end user"
4.8.8 Should say that because of the typical inability to use Schema inheritance then xmi:type rather than xsi:type is generally used
4.9 states "In XMI 2, a schema generator can decide whether to support the exchange of model fragments." This should be predicatble and e.g. controlled by tags in the metamodel
4.10.1 has the following bullet. "Links are always to elements of the same type or subclasses of that type. Restricting proxies to reference the same element type reduces complexity, enhances reliability and type safety, and promotes caching. In XMI 2, subclasses are also allowed, to permit more flexibility in combining models." This seems to state a principle and then state that it's not applied to XMI 2: why not just delete it?
4.10.1 the following bullet is misleading: "When acting as a proxy, XML attributes may be defined, but not contents. The XML attributes act as a cache that gives an indication if the link should be followed." and should be reworded: "When acting as a proxy, XML attributes may be used, but not contents. The XML attributes act as a cache or guide that gives an indication of the element values if the link were to be followed: however there is no gurante that these cached values accurately represent the current values of the linked element
4.10.1 to the bullet "It is efficient practice for maximizing caching and encapsulation to use local proxies of the same element within a document to link to a single proxy that holds an external reference." add "This is particularly useful when referencing predefined DataTypes such as the PrimitiveTypes String, Integer etc."
4.10.1 last bullet: "Association role elements typically contain proxies that link to the definitions of the classes that participate in the association." I do not understand this, and it is not practiced in any standard metamodels. Propose delting the bullet.
4.10.2.1 should also mention the use of XML attributes representign class-typed properties in the metamodel
4.10.2.2 states "Supporting links across documents is optional." however this is not mentioned in any other section including the compliance section. This sentrence should be deleted.
Defer: While the Issue may be valid, it represents potentially significant modifications. Thus, this Issue will be deferred and handled by work on a later version of BPMN.
4.10.2.2 has the example "<mgr xmi:id="mgr_1" href="Co.xml#emp_2"/>" however "Co.xml" is not a valid URI! It is use in several of the examples
4.11 states "Typically, the Tags could be in a separate Package and a 'super' package could cluster this Tags package and the model package to drive the Schema generation." however MOF2 does not have clustering.
4.11, table 4.1: the definitions of the tags 'element' and 'attribute' do not state what happens if they are false. The fact that they both default to false implies that by default nothing gets serialized! In practice the normal behavior (documented elsewhere in the spec) is to create both elements and attributes where allowed - I think the explanations should state that 'attribute' means 'serialize *only* as an XML attribute (not as an element)'. This is borne out by 4.11.7 which states "The XMI 'element' tag can be used to signal that attributes can be serialized only as XML elements." And similarly for 'element'. In which case there should be the additional constraint that attribute and element cannot both be true.
4.11, table 4.1: 'complex' is repeated in the list of values for contentType
In 4.11.2, and elsewhere in the spec, tag names should be in bold, or the full name used e.g. org.omg.xmi.ordered
In 4.11.2 the statement "If useSchemaExtensions is true, the MOF model must not have multiple inheritance." would be better expressed "If the MOF model has multiple inheritance then useSchemaExtensions must be false"
In table 4.1 the href attribute is described thus "If true, use the href attribute rather than the idref attribute for links within a document". To be meaningful the following should be added "this also prohibits the use of XML attributes for class-typed properties". And 4.11.2 should add the constraint that if Href=true then attribute=false and element=true.
The last bullet of 4.11.2 starts "If the isProperty tag is true, the" - this should refer to "idProperty". In the same bullet "The tagged property must have type Datatype." should be "The tagged property must be Datatype-typed."
4.11.3 is largely redundant with, and should be merged with, 4.11.5
4.11.6, 4.11.7 has: schemaLocation="xmi20.xsd" which is wrong for XMI 2.1.
4.11.7 has: xmlns:xmi="http://www.omg.org/XMI" which is wrong
4.11.7 uses a type "GM_Curve£ which is not defined or described. It is for some reason represented as xsd:strign in the XSD. Likewise CharacterString
4.11.7 contains several xsd:annotation elements which are neither required nor described as an option by the spec. They should be removed
4.11.7: the attribute Mountain::elevation has been declared as type xsd:string despite being defined as an Integer. It has been changed to xsd:int in the 'improved' schema though with no explanation. The built in Primitive Integer has its xsd type defined as xsd:int so this should be in the default example also.
4.11.7: the example should make clear whether this is a CMOF or EMOF metamodel