Issues for XMI Production of XML Schema Finalization Task Force

To comment on any of these issues, send email to xml-schema-ftf@omg.org. (Please include the issue number in the Subject: header, thusly: [Issue ###].) To submit a new issue, send email to issues@omg.org.

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

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

Issue 4638: More use of schema structural constraints
Issue 4642: Introduce extenderVersion
Issue 5304: XMI Schema Issue - representation for Associations

Issue 4638: More use of schema structural constraints (xml-schema-ftf)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity: Minor
Summary:
It is not clear why a separate XML construct has not been used for proxies
(as described in 4.9) - rather than leaving an importer to check for the
presence of link attributes. And providing no Schema-level enforceable
constraint that proxies have no content (and vice versa).
It would also help to have a stronger statement with respect to the use of
XMI attributes as a 'cache' within proxies: to what extent must they be
accurate and what options does an importer have if they are not? Does
validation include checking the accuracy of cached attributes?
4.6.2: Could Schema mechanisms be used to enforce the constraint that only
one of href and idref is to be used?


Resolution:
Revised Text:
Actions taken:
October 23, 2001: received issue
May 29, 2002: issue deferred

Issue 4642: Introduce extenderVersion (xml-schema-ftf)

Click
here for this issue's archive.
Nature: Uncategorized Issue
Severity: Minor
Summary:
4.5.3: It would be useful to have an extenderVersion to match
exporterVersion.

Resolution:
Revised Text:
Actions taken:
October 23, 2001: received issue
May 29, 2002: : issue deferred

Issue 5304: XMI Schema Issue - representation for Associations (xml-schema-ftf)

Click
here for this issue's archive.
Source: Adaptive (Mr. Pete Rivett, pete.rivett(at)adaptive.com)
Nature: Uncategorized Issue
Severity:
Summary:
Association elements are essential for referenceless associations, and can
be very useful for creating links between existing objects for associations
with references also (the latter should be optional controlled by a new
tag).
They are not mentioned at all in section 4 (Schema Design Principles)
despite appearing as Rule Set 10 in 5.2.1. and Rule Set 7 in 5.3.1.


Also the schema and document generation rules for Association elements are
unnecessarily heavyweight and inconsistent with the treatment of references
on classes. For example it does not make sense for an AssociationEnd element
to have the fixed xmi attributes; and it should be possible to dispense with
them completely: letting an Association element refer to the linked elements
using XML attributes. e.g. for association A with ends b and c, a link could
be represented as follows (b1 and c1 are xmi.id's):  <A b=b1 c=c1 />).

Resolution:
Revised Text:
Actions taken:
May 17, 2002: received issue
May 31, 2002: deferred issue

Discussion:
Proposed resolution:


A) Add new section 4.7.6 as below and renumber existing sections 4.7.6,
4.7.7 and 4.7.8.
4.7.6 Association Specification
Each association and association end is also represented by an XML element.
This is essential for associations where both association ends have no
corresponding reference in the linked class, but can also be useful for
linking objects even when references are present: the latter are only
generated if the generateAssociationElements tag is set to 'true'.
The declaration uses the same style for the association ends within the
association as for references within a class.
The following is the representation of metamodel association named "A"
linking classes "B" and "C" via association ends "b" and "c". (This assumes
that B and C have no subclasses).


B) Add the following Tag to section 4.10.1 under heading "XML Schema
Production"
 generateAssociationElements | boolean | false | If true, generate element
definitions for all associations. If false, generate element definitions
only for referenceless associations.


C) 5.2.1 Add to the end of description for rule 9f:
However it is also useful to be able to instantiate Associations by
specifying links, even when they do have references, so at all Associations
in the Package will be listed.


D) 5.2.1 Change the description of Rule 10 from:
The XML elements for unreferenced Associations consist of definitions for
its AssociationEnds and for the Association itself.


to:
The XML elements for Associations consist of definitions for its
AssociationEnds and for the Association itself.


E) 5.2.1 Change Rule Set 11 from:
11. AssociationEndDef ::= "<xsd:element name=’" 12b:AssnName "."
11b:AssocEndName "’>
<xsd:complexType >"
11c:AssocEndAtts
"</xsd:complexType>
</xsd:element>"
11a. AssocEndElmtName ::= 12b:AssnElmtName "." 11b:AssocEndName
11b. AssocEndName ::= //Name of AssociationEnd//
11c. AssocEndAtts ::= 1g:XMIFixedAttribs
11. The declaration for an AssociationEnd XML element has no content model,
though
it has the standard set of XML attributes.


to:


11. AssociationEndDef ::= "<xsd:element name=’" 12b:AssnName "."
11b:AssocEndName "’>
<xsd:complexType >"
11c:AssocEndContents
"</xsd:complexType>
</xsd:element>"
11a. AssocEndElmtName ::= 12b:AssnElmtName "." 11b:AssocEndName
11b. AssocEndName ::= //Name of AssociationEnd//
11c. AssocEndContents ::= ("<xsd:element ref=’" 6a:ClassElmtName "’/>")+
11. The declaration of an AssociationEnd element within an Association is
the same as that for a ReferenceElement within a Class (see Rule Set 5): the
only exception is in Rule 11 where at most one class instance may be
referred to by each link.


F) In 5.2.1 change the description of Rule 12d and add new rule 12e. from:
12d. AssnAtts ::= 1g:XMIFixedAttribs
to
12d. AssnAtts ::= 12e:AssnAttribRef 12e:AssnAttribRef 1g:XMIFixedAttribs
12e. AssnAttribRef ::= "<xsd:attribute name=’" 11b:AssocEndName "’"
"type=’xsd:IDREF’ use=’optional’/>"


Change the descriptions for RuleSet 12 from:
12, 12c. The declaration of an unreferenced Association consists of the
names of its AssociationEnd XML elements.
12a. 12b. The name of the XML element representing the Association.
12d.The fixed identity and linking XML attributes are the Association XML
attributes.


to:
12, 12c. The declaration of an Association consists of the names of its
AssociationEnd XML elements.
12a. 12b. The name of the XML element representing the Association.
12d. As for references from classes, XML attributes may be used instead of
AssociationEnd elements. The fixed identity and linking XML attributes are
also Association XML attributes.
12e. The attribute will represent a reference to a single element.



G) 5.3.1 Add to the end of rule 6e:
However, if the tag org.omg.xmi.generateAssociationElements is true, all
Associations are listed as part of the Package contents.



H) Change Rule Set 7 in 5.3.1 from:
7. AssociationDef ::= "<xsd:element name=’" //Name of association// "’>"
"<xsd:complexType>
<xsd:choice minOccurs=’0’ maxOccurs=’unbounded’>"
7b:AssnContents
"</xsd:choice>"
7d:AssnAtts
"</xsd:complexType>
</xsd:element>"
7a. AssnElmtName ::= 1c:Namespace //Name of association//
7b. AssnContents ::= 7c:AssnEndDef
7c:AssnEndDef
4c:Extension
7c. AssnEndDef ::= "<xsd:element"
"name= ’" //Name of association end// "’>"
"<xsd:complexType>"
1g:XMIFixedAttribs
"</xsd:complexType>"
"</xsd:element>"
7d. AssnAtts ::= 1g:XMIFixedAttribs


7. The declaration of an unreferenced Association consists of the names of
its
AssociationEnd XML elements.
7a. The use of the name of the XML element representing the Association.
7d. The fixed identity and linking XML attributes are the Association XML
attributes.


to:
7. AssociationDef ::= "<xsd:element name=’" //Name of association// "’>"
   "<xsd:complexType>
      <xsd:choice minOccurs=’0’ maxOccurs=’unbounded’>"
        7b:AssnContents
     "</xsd:choice>"
     7d:AssnAtts
  "</xsd:complexType>
 </xsd:element>"
7a. AssnElmtName ::= 1c:Namespace //Name of association//
7b. AssnContents ::= 7c:AssnEndDef 7c:AssnEndDef 4c:Extension
7c. AssnEndDef ::= "<xsd:element"
   "name= ’" //Name of association end//
    (("type=’" 4a:ClassTypeName "’/ >") |
      (">" 4o:Any "</xsd:element>) )
    "</xsd:element>"
7d. AssnAtts ::= ( 7e:AssnAttribRef 7e:AssnAttribRef )?
    1g:XMIFixedAttribs
7e. AssnAttribRef ::= "<xsd:attribute name=’" //Name of association end// "’
"
    "type=’xsd:IDREF’ use=’required’/>")


7. The XML elements for Associations consist of definitions for its
AssociationEnds and for the Association itself.
7a. The use of the name of the XML element representing the Association.
7c. The declaration of an AssociationEnd element within an Association is
the same as that for a ReferenceElement within a Class (see Rule Set 4): the
only exception is in Rule 7c. where at most one class instance may be
referred to by each link.
7d. The fixed identity and linking XML attributes are the Association XML
attributes.
7e. This uses the same form as for references within classes as defined in
rule 4i.


I) In 6.3.8 renumber the descriptions to refer to rules 8, 8a, 8b (the
descriptions are numbered wrongly in the original document) and change the
description for 8 (formerly 7) from:
"All associations which have no references are placed here. Each
associationEnd’s links are contained as pairs of nested XML elements."


to:
"All associations that have no references are placed here. For import any
associations may be placed here. Each associationEnd’s links are contained
as pairs of nested XML elements. As an alternative XML attributes may be
used to refer to the linked elements as for references on class elements:
this will use rule 3j (RefValueAttrib) in the expansion of 3b with the name
of the association end as the reference name and the restriction that only
one value is permitted."