Issues for XMI 2.1 Revision Task Force

List of issues (green=resolved, yellow=pending Board vote, red=unresolved)

List options: All ; Open Issues only; or Closed Issues only

Issue 5950: XMI 2.0 issue: Proxies and Multiplicities
Issue 5975: Schema production rule 4d clarification request
Issue 5981: More type safety in generated schemas
Issue 6008: Incosistent XMI namespace URL
Issue 6009: The ClassAttribRef Production Rule (4i) can be enhanced
Issue 6010: Schema production rule for 'ClassReferences' (4.e)
Issue 6011: tag value constraint in chapter 1.11.2
Issue 6054: Are xlinks legal?
Issue 6065: Remarks to chapter "3.4.3 Derived Types and References" in XMI Spec. , v 2
Issue 7334: How are attributes and compositions inherited?
Issue 9358: Page: 58
Issue 9359: Page: 60
Issue 12407: How to serialize values of the PrimitiveType UnlimitedNatural

Issue 5950: XMI 2.0 issue: Proxies and Multiplicities (xmi21-rtf)

Doc references are based on formal/03-05-02.


In a Schema that is produced by the XML Schema Production
rules, enforcement of multiplicities is incompatible with
the use of proxies.


According to 1.10.1, page 1-21, "Elements act as a union,
where they are either a definition or a proxy. Proxies use
the LinkAttribs attribute group to define the link, and
contain no nested elements."


However, if the org.omg.xmi.enforceMinimumMultiplicity is
true, then the generated schema does not allow the complex-
Type's content to be empty, and so proxies cannot exist in
an XML document.


As a simple fix, the 4b:ClassContents could be wrapped into
an additional choice element, as in


  <xsd:choice minOccurs="0">
    <xsd:sequence>
      4b:ClassContents
    </xsd:sequence>
  </xsd:choice>


This would allow the element to be empty. However, in this
form, an XML document that contained both link attributes
and contents would still validate.


A stronger solution would be to make a choice *between* a
link element and contents, by removing the LinkAttribs from
the ObjectAttribs attribute group and by, in rule set 4,
defining something along the lines of


  <xsd:choice>
    <xsd:sequence>
      4b:ClassContents
    </xsd:sequence>
    <xsd:element name="href" type="xsd:string">
    <xsd:element name="idref" type="IDREF"> 
  </xsd:choice>


This way, an element in a validating document could only be
either a proxy or not.


As a side note to this issue, there are obviously unpleasant
side effects when org.omg.xmi.enforceMinimumMultiplicity is
true and org.omg.xmi.element is false. org.omg.xmi.enforce-
MinimumMultiplicity=true should have the same effect as
if org.omg.xmi.element=true and org.omg.xmi.attribute=false.

Document refs are against formal/03-05-02.


Maybe it's because I'm still struggling with the details
of XML Schemas and MOF, but I'm confused with rule 4d of
the XML Schema Production rules (EBNF on page 2-4, expla-
nation on page 2-5).


- According to the EBNF, a type='xmi:Any' is an output
  option, but according to the explanation, this option
  is never used.


- The explanation goes, "The type is 'xsd:string' for simple
  attributes ..." It is not clear to me what constitutes a
  "simple" vs. "non-simple" attributes. I assume this refers
  to MOFs PrimitiveTypes, but in any case a clarification
  would be useful.


- The explanation goes on, "The type is [...] part of the
  of the value of the org.omg.xmi.schemaType tag". Why does
  it say "part of"? What should be removed from the value?


- There is also a question of precedence. I guess the
  intention is that the schemaType tag should take
  precedence over the "simple attribute" decision?


- There is no "else:" What if the attribute is not simple,
  not an enumeration, and the schemaType tag is not set?
  (Or maybe that is not possible in MOF?)

Document refs are against formal/03-05-02.


According to rule 4d of the Schema production rules on page 2-5,
"The type is 'xsd:string' for simple attributes".


I assume here that "simple attributes" refers to MOF primitive
types (Boolean, Integer, Long, Float, Double, String).


I wonder why xsd:string was used for all these primitive types,
when perfectly suitable data types are predefined for XML Schemas:
there's xsd:boolean, xsd:int, xsd:long, xsd:float and xsd:double
that exactly match the data types used by MOF.


I propose to make use of these existing types to strengthen the
generated schema.

Section 1.10.2.2 (page 1-23) gives the URL for the xmi namespace
as http://schema.omg.org/spec/XMI/2.0


Section 2.2.1 (page 2-2) uses http://www.omg.org/XMI instead

The ClassAttribRef Production Rule (4i) can be enhanced by adding a minLength/maxLength facette to the reference attribute. With this facette the cardinality can be constrained. 

The Schema production rule for 'ClassReferences' (4.e) does not conform with the Document Production Rule 'Reference Element' (4). In the Class References the linking attribues are missing

Schema Production Rule 4i says, if tag enforceMinimumMultiplicity is true, IDREF is required. But tag value constraint in chapter 1.11.2 says, that with the enforceMultiplicity tag, attributes must be serialized as elements.

maybe this is just because of my ignorance, but I'm running into
a problem trying to validate documents against an XMI based schema
here, and it looks like the validator has a point.


As usual, my base document is XMI 2.0, formal/03-05-02.


Section 1.10.2 "Linking" describes the usage of XLink simple links
and XPointers to link across documents.


However, looking at the schema production rules (page 2-2 to 2-5,
rules 4g:ClassAttListItems and 1g:XMIFixedAttribs, as well as the
LinkAttribs attributeGroup in the Fixed Schema Declarations on
page 2-10, the xlink:href is never declared as a legal attribute
for complexTypes.


Hence I see why the parser (Xerces-C, when requested to validate)
complains about attempts to use XLinks in a document.


I think it is paramount that documents validate against the schema.
(Am I the first to attempt validation? Can't be.)


I realize that there doesn't seem to be a schema for XLinks yet,
so the short-term solution might be to allow the "normal" href
attribute to contain an XPointer.


As a minor nitpicking, page 1-23 gives the XLink namespace as
"http://www.w3.org/1999/XLink", whereas the W3C recommendation
for XLink uses "http://www.w3.org/1999/xlink" (note case).

Issue also important to MOF 2.0 XMI FTF

Remarks to chapter "3.4.3 Derived Types and References" in  XMI Spec. , v 2.0, S. 3-15
There it says:

"... An instance of Company can use xsi:type to
indicate that its HQAddress is actually of type USAddress and includes a zipcode:
<Company xmi:id="Company_1" name="Acme">
<HQAddress xmi:type="USAddress" xmi:id="Address_1"
Street="Side Street" City="Hometown" zipcode="90210"
... "
The 'HQAdress'-Element has a 'xmi:type'-Attribute. Parsing this with Xerces 2.4.0 gives problems, since a 'xsi:type' Attribute is required. Derived types must be specified with the 'xsi:type'-Attibute. Maybe the line
    "... An instance of Company CAN use xsi:type ..." 
should be changed in 
    " ... An instance of Company MUST use xsi:type ..."

In my understanding of the XMI 2.0 spec, it is not clear about how attributes and compositions are inherited. On page 34 point 1.8.7 is stated, that for attributes and compositions copy-down inheritance is required. Contrarily is rule 4c on page 57, which states that only local attributes, references, and compositions are included if the org.omg.xmi.useSchemaExtensions is set to true.

There are two issues in this section of the document pertaining to referencing elements which only exist in the specification for the previous version, formal/05-05-01 (which is a changebar version of formal/03-05-02). First issue: 1:Document references 2:ContentElements. Here, 2:ContentElements does not exist in the formal/05-09-01 specification. Second issue: 1a:XMI references 5j:Extension. Here, 5j:Extension does not exist in the formal/05-09-01 specification. 

There are two typo's for element 2h:FeatureAttrib. >From Document: ------------------- 2h:FeatureAttrib ::= X2i:MIValueAttribute | 2jXMIReferenceAttribute ------------------- - X is misplaced for 2i element - missing colon for 2j element Should be: ------------------- 2h:FeatureAttrib ::= 2i:XMIValueAttribute | 2j:XMIReferenceAttribute ------------------- 

The XMI is not explicit as to how to serialize values of the PrimitiveType UnlimitedNatural. In practice, and in the normative metamodels for UML as well as MOF, the value ‘*’ has been used to represent ‘unlimited’ (as opposed to the value ‘-1’ which was used at UML/MOF 1.x). Rule 2i in section 6.3 states: Use this production rule to serialize an attribute whose type is not an object and whose value can be represented by a string. Multi-valued attributes cannot be serialized as XML attributes. If the attribute’s type is one of the types defined by the XML Schema Part 2: Datatypes specification, serialize the value as specified in that specification. PROPOSED RESOLUTION Add the following sentence to the end of the above paragraph: “Unless specified otherwise, values of other types may be serialized as strings using any permitted visual notation for that type. This applies to values for the Primitive Type UnlimitedNatural, where unlimited is serialized, as well as displayed, as ‘*’.