Issues for XMI 2.6 Revision Task Force

To comment on any of these issues, send email to [email protected]. (Please include the issue number in the Subject: header, thusly: [Issue ###].) To submit a new issue, send email to [email protected].

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

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

Issue 7602: Type specification of MOF attributes (mof2xmi-rtf)

Click here for this issue's archive.
Nature: Clarification
Severity: Critical
Summary:

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.

Resolution: (now sections 4.8.4 and 5.2.1) �simple attribute� is actually a well established term, meaning an attribute which can be represented as a single value. Also the MOF 1.4 types mentioned in the issue: CollectionType and AliasType are no longer present in MOF 2.x See resolution for issue 8884 regarding structured DataTypes. Revised Text: - none - Proposed Disposition: Closed � No Change
Revised Text:
Actions taken:
July 27, 2004: received issue
May 27, 2011: closed issue

Issue 7603: Missing rule for generating type or element declarations (mof2xmi-rtf)

Click here for this issue's archive.
Nature:
Severity:
Summary:

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.

Resolution: Resolution: MOF has never permitted nested classes in metamodels: Class::nestedClassifier was added in UML superstructure. For MOF 2.4 which is based on Superstructure, an explicit constraint was added, as part of MOF Issue 15398, that for metamodels Class::nestedClassifier must be empty. Hence no XMI rule is needed for these. Revised Text: - none - Disposition: Closed � No Change
Revised Text:
Actions taken:
July 27, 2004: received issue
May 27, 2011: closed issue

Discussion:

Issue 7604: Section 2.2.1, rule 6f (mof2xmi-rtf)

Click here for this issue's archive.
Nature: Clarification
Severity: Critical
Summary:

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.

Resolution: As per the resolution to 9694, PackageElements serve no purpose and so this can also clear up this issue � by deleting the whole of rule 6 in section 5.2. Revised Text: (see resolution of issue 9694) Disposition: Closed � Duplicate / Related to 9694
Revised Text:
Actions taken:
July 27, 2004: received issue
May 27, 2011: closed issue

Issue 8321: opaque content (mof2xmi-rtf)

Click here for this issue's archive.
Nature: Enhancement
Severity: Significant
Summary:

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=" &lt;math xmlns=&quot;&math;&quote;&gt; &lt;apply&gt; &lt;eq/&gt; &lt;ci&gt;F&lt;/ci&gt; &lt;apply&gt; &lt;times/&gt; &lt;ci&gt;m&lt;/ci&gt; &lt;ci&gt;a&lt;/ci&gt; &lt;/apply&gt; &lt;/apply&gt; &lt;/math&gt; &lt;/math&gt; "/> </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

Resolution: Note: The sample XMI in the issue is not valid in that it shows instances of SysML stereotypes nested within their owning UML elements. Furthermore, as the issue later acknowledges, XMI allows properties to be serialized as XML elements instead of XML attributes: this can be forced by setting org.omg.xmi.attribute to true at either the property or Class or package/profile level. The issue asks: �In UML2 specification is multiplicity [0..1]; is there no mechanism for specifications in multiple languages? � Though not an XMI question, the answer is �yes�: in Finalization of UML 2.0, OpaqueExpression::body and OpaqueExpression::language were made multi-valued. The substantive issue is how to allow nesting of other XML in the attribute value. This can be achieved by using xsd:anyType as the value of the org.omg.xmi.schemaType property. This validates the following: <body> <math xmlns="math"> <apply> <eq/> <ci>F</ci> <apply> <times/> <ci>m</ci> <ci>a</ci> </apply> </apply> </math> </body> This Tag could even be added to the UML metamodel by the SysML Profile XMI to change the serialization specifically for SysML (though this would risk interoperability with UML tools). Revised Text: - none - Disposition: Closed � No Change
Revised Text:
Actions taken:
February 23, 2005: received issue
May 27, 2011: closed issue

Issue 8437: Section: 8 (mof2xmi-rtf)

Click here for this issue's archive.
Nature: Revision
Severity: Minor
Summary:

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

Resolution: This is now section 5.2.1. There are more syntax errors in the EBNF rules than pointed out in the original issue, and the current formatting of the EBNF rules in the document allows ambiguous interpretation. Therefore, most EBNF rules in section 5.2.1 will be replaced.
Revised Text: In section 5.2.1, replace EBNF Rules 1 to 1h with the following rules: 1. Schema ::= 1a:SchemaStart 1d:ImportsAndIncludes? 1e:FixedDeclarations 2:PackageSchema+ 1f:SchemaEnd 1a. SchemaStart ::= "<xsd:schema xmlns:xsd=�http://www.w3.org/2001/XMLSchema� xmlns:xmi=�https://www.omg.org/spec/XMI/20100901�" 1b:NamespaceDecl* 1c:TargetNamespace? ">" 1b. NamespaceDecl ::= "xmlns:" //Namespace prefix// "=" "�" //Namespace URI// "�" 1c. TargetNamespace ::= "targetNamespace=�" //Namespace URI// "�" 1d. ImportsAndIncludes ::= //Imports and includes// 1e. FixedDeclarations ::= "<xsd:import namespace=�https://www.omg.org/spec/XMI/20100901�/>" 1f. SchemaEnd ::= "</xsd:schema>" 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�/>" 1h. Namespace ::= ( //Name of namespace// ":" )? In section 5.2.1, replace EBNF Rules 4 to 4o with the following rules: 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> 4a. ClassTypeName ::= 1h:Namespace //Name of Class// 4b. ClassContents ::= 4d:ClassAttributes 4e:ClassReferences 4f:ClassCompositions 4c:Extension 4c. Extension ::= ("<xsd:element ref=�xmi:extension�/>")* 4d. ClassAttributes ::= ("<xsd:element name=�" //Name of Attribute// "�" ("nillable=�true�")? ( 4m:MinOccursAttrib )? ( 4n:MaxOccursAttrib )? (("type=�" //Name of type// "�/>") | ("type='xmi:Any'/>")) )* 4e. ClassReferences ::= ( "<xsd:element name=�" //Name of Reference// "�" ( 4m:MinOccursAttrib )? ( 4n:MaxOccursAttrib )? (("type=�" 4a:ClassTypeName "�/>") | ("type='xmi:Any'/>")) )* 4f. ClassCompositions ::= ( "<xsd:element name=�" //Name of Reference// "�" ( 4m:MinOccursAttrib )? ( 4n:MaxOccursAttrib )? (("type=�" 4a:ClassTypeName "�/>") | ("type='xmi:Any'/>")) )* 4g. ClassAttListItems ::= 1g:XMIFixedAttribs 4h:ClassAttribAtts 4h. ClassAttribAtts ::= ( 4i:ClassAttribRef | 4j:ClassAttribData | 4k:ClassAttribEnum )* 4i. ClassAttribRef ::= "<xsd:attribute name=�" //Name of attribute// "�" ("type=�xsd:IDREFS� use=�optional�/>" | "type=�xsd:IDREF� use=�required�/>" | (QName ? "type=�xsd:anyURI� use=�optional�/>")) 4j. ClassAttribData ::= "<xsd:attribute name=�" //Name of attribute// "�" "type=�xsd:string� " ("use=�optional�" | "use=�required�") ("default=�" 4l:ClassAttribDflt "�")? ("fixed=�" 4o:ClassAttribFixed "�")? ("form=�" //Form value// "�")? "/>" 4k. ClassAttribEnum ::= "<xsd:attribute name=�" //Name of attribute// "�" "type=�" 8a:EnumTypeName "�" (("use=�default�" "value=�" 4l:ClassAttribDflt "�") | ("use=�optional�" | "use=�required�")) "/>" 4l. ClassAttribDflt ::= //Default value// 4m. MinOccursAttrib ::= "minOccurs=�" //Minimum// "�" 4n. MaxOccursAttrib ::= "maxOccurs=�" //Maximum// "�" 4o. Class AttribFixed ::= //Fixed value// In section 5.2.1, replace EBNF Rules 7 to 7d with the following rules: 7. AssociationDef ::= "<xsd:element name=�"� 7a:AssnElmtName �"�>" "<xsd:complexType> <xsd:choice minOccurs=�0� maxOccurs=�unbounded�>" 7b:AssnContents "</xsd:choice>" 7d:AssnAtts "</xsd:complexType> </xsd:element>" 7a. AssnElmtName ::= 1h: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 In section 5.2.1, replace EBNF Rules 8 to 8d with the following rules: 8. EnumSchema ::= "<xsd:simpleType name=�" 8a:EnumTypeName "�>" "<xsd:restriction base=�xsd:string�>" 8c:EnumLiterals "</xsd:restriction>" "</xsd:simpleType>" 8a. EnumTypeName ::= 1h:Namespace 8b:EnumName 8b. EnumName ::= //Name of enumeration// 8c. EnumLiterals ::= ("<xsd:enumeration value=�" 8d:EnumLiteral "�/>")+ 8d. EnumLiteral ::= //Name of enumeration literal//
Actions taken:
March 2, 2005: received issue
April 25, 2011: closed issue

Issue 8438: Section: 9 (mof2xmi-rtf)

Click here for this issue's archive.
Nature: Revision
Severity: Minor
Summary:

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=�https://www.omg.org/XMI�" | "xmlns:" 1h:NsName "=�https://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.

Resolution: This is now section 6.4.1. There are more errors in the EBNF rules than pointed out in the original issue, and the current formatting of the EBNF rules in the document allows ambiguous interpretation. Therefore, all EBNF rules in section 6.4.1 will be replaced, and the missing rule �3. Extension� added.
Revised Text: In section 6.4.1, replace the EBNF Rules 1 to 1i with the following rules: 1:Document ::= 1a:XMI | 2:ContentElements 1a:XMI ::= "<xmi:XMI" 1c:StartAttribs ">" ( 2a:XMIObjectElement)* ( 3:Extension )* "</xmi:XMI>" 1b: (rule deleted) 1c:StartAttribs ::= 1d:XMIVersion 1e:Namespaces 1d:XMIVersion ::= "xmi:version=�" //XMI version// "�" 1e:Namespaces ::= 1f:XMINamespaceDecl ( "xmlns:" 1h:NsPrefix "=�" 1i:NsURI "�" )* 1f:XMINamespaceDecl ::= "xmlns:xmi =�https://www.omg.org/XMI�" 1g:Namespace ::= ( 1h:NsName ":" )? 1h:NsPrefix ::= //Prefix of namespace// 1i:NsURI ::= //URI of namespace// Delete the text entry for rule 1b. In section 6.4.2, replace the EBNF Rules 2 to 2n with the following rules: 2:XMIElement ::= 2a:XMIObjectElement | 2b:XMIValueElement | 2c:XMIReferenceElement 2a:XMIObjectElement ::= ( "<" 2k:QName 2d:XMIAttributes "/>" ) | ( "<" 2k:QName 2d:XMIAttributes ">" (2:XMIElement)* "</" 2k:QName ">" ) 2b:XMIValueElement ::= ( "<" //xmiName// ">" //value// "</" xmiName ">" ) | ( "<" //xmiName// "nil='true'/>" ) 2c:XMIReferenceElement ::= "<" //xmiName// (2g:TypeAttrib)? 2l:LinkAttribs "/>" 2d:XMIAttributes ::= (1c:StartAttribs)? (2e:IdentityAttribs)? (2g:TypeAttrib)? (2hFeatureAttrib)* 2e:IdentityAttribs ::= ( 2f:IdAttribName "=�" //id// "�")? ( //xmiPrefix// "label=�" //label// "�" )? ( //xmiPrefix// "uuid=�" //uuid// "�" )? 2f:IdAttribName ::= //xmiPrefix// "id" | //xmiIdAttribName// 2g:TypeAttrib ::= (1b:XMINamespace | 1g:Namespace) "type=�" 2k:QName "�" 2h:FeatureAttrib ::= 2i:XMIValueAttribute | 2j:XMIReferenceAttribute 2i:XMIValueAttribute ::= //xmiName// "=�" //value// "�" 2j:XMIReferenceAttribute ::= //xmiName// "=�" ( //refId// | 2n:URIref )+ "�" 2k:QName ::= ( //prefix// ":" )? //xmiName// 2l:LinkAttribs ::= 1b:XMINamespace "idref=�" //refId// "�" | 2m:Link 2m:Link ::= "href='" 2n:URIref "'" 2n:URIref ::= (2k:QName)? //URI reference// After section 6.4.2, and before section 6.5, insert the new section heading: 6.4.3 Extension followed by this EBNF Rule: 3:Extension ::= "<" 1b:XMINamespace "extension" �xmi:type=�xmi:Extension�� (" extender=�" // extender // "�")? (" extenderID=�" // extenderID // "�")? ">" // Extension elements // "</" 1b:XMINamespace "extension>" Then followed by this rule description: 3 Extension elements may be provided to complement the serialized model with additional information, such as tool-specific diagram data, for example. Each extension element has an optional extender and extenderID attribute; its content can be anything (See section 4.13 for examples).
Actions taken:
March 2, 2005: received issue
April 25, 2011: closed issue

Issue 8795: Unclear serialization of derived data (mof2xmi-rtf)

Click here for this issue's archive.
Source: Adaptive (Mr. Pete Rivett, pete.rivett(at)adaptive.com)
Nature: Uncategorized Issue
Severity: Critical
Summary:

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"."

Resolution: This has already been resolved and completed in a previous RTF. Close no change. Disposition: Closed � No Change
Revised Text:
Actions taken:
May 22, 2005: received issue
May 27, 2011: closed issue

Issue 8884: Impractical representation of structured datatypes (mof2xmi-rtf)

Click here for this issue's archive.
Source: Adaptive (Mr. Pete Rivett, pete.rivett(at)adaptive.com)
Nature: Uncategorized Issue
Severity:
Summary:

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.

Resolution: The serialization of structured datatypes as flattened strings is inconvenient at minimum, but frequently ambiguous so that it cannot be parsed back into correct value assignments to the corresponding fields of the structured datatype. Revert to the class-like serialization of XMI 2.0 and allow flattening only for non-nested structured datatypes with field multiplicity [1..1] as a special case, controlled by a new tag org.omg.xmi.flattenStructuredDataTypes, which shall default to false.
Revised Text: In section 4.8.7, locate the paragraph starting with: �In CMOF, datatypes can have properties, which in effect allows them to be structured datatypes.� Replace this whole paragraph with the following text: In CMOF, datatypes, other than Primitive and Enumeration Types, can have properties, which in effect allows them to be structured datatypes. During serialization, structured datatypes are treated like classes with properties, reusing the document production rules starting with rule 2a:XMIObjectElement (see section 6.4.2) with the following adaption: � The name of the structured datatype is used instead of the class name. Serializing structured datatypes analogous to classes is the default. The org.omg.xmi.valueSeparator tag has no effect on this form of serialization. Primarily for backward compatibility, flattening of structured datatypes may be performed if all of the following conditions hold: � The structured datatypes are not nested (i.e. do not contain structured datatypes as one or more fields). � The fields have multiplicity [1..1]. � The tag org.omg.xmi.flattenStructuredDataTypes (which defaults to false) is set to true. After the class symbol for Point, replace the following first line by: Using the class-like default serialization, an example of a graph with two points would serialize as: <g:Graph xmi:type=�g:Graph�> <points xmi:type=�g:Point� x="0" y="0"/> <points xmi:type=�g:Point� x="1" y="5"/> </g:Graph> But using the special case flattened serialization (with org.omg.xmi.flattenStructuredDataTypes=true), the point coordinates would serialize as strings. The separator between the coordinate values is controlled by org.omg.xmi.valueSeparator: Replace all text following the Rectangle class symbol with the following text: This example shows the nesting of two structured datatypes. The only valid serialization for a property called area of type Rectangle is: <display xmi:type=�g:Viewport�> <area xmi:type=�g:Rectangle�> <upperLeft xmi:type=�g:Point� x="0" y="5"/> <lowerRight xmi:type=�g:Point� x="4" y="0"/> </area> </display> In the example in section 6.5.3.1, replace the text: <ViewPort name= 'myVP' area=",1,2,3,4" /> �area� is serialized as a string in which the lowest level datatype properties appear, separated by commas. In this example: By: <display xmi:type=�g:Viewport� name=�normal�> <area xmi:type=�g:Rectangle�label=��> <upperLeft xmi:type=�g:Point� x="1" y="2"/> <lowerRight xmi:type=�g:Point� x="3" y="4"/> </area> </display> Insert a new tag into table 4.1, XML Schema Production section: Tag Name Value Type Default Value Description flattenStructuredDataTypes boolean false If set to true, instances of non-nested structured datatypes with field multiplicities [1..1] may be serialized as a string of values separated by the separator defined by the valueSeparator tag. Insert the same tag also in table 4.2: XMI Tag MOF Constructs Affected Package Scope Class Scope Construct Scope flattenStructuredDataTypes Property X X X Add the datatypes in the BNF in Section 5.2.1 add the following line in rule 2 after: | 3:ClassSchema By | 6:StructuredDataTypeDef And in the note for 2. follow �Classes� by �,Structured DataTypes (those with properties)� Note that the previous content of Rule 6 has been deleted by an already accepted issue resolution. Add new rule 6 as follows: 6. StructuredDataTypeDef::= "<xsd:complexType name=�" //Name of DataType// ("mixed=�true�")? "�>" ( "<xsd:complexContent>" "<xsd:extension base=�" 6a:DataTypeName ("<xsd:choice minOccurs=�0� maxOccurs=�unbounded�>" | "<xsd:sequence>")? ( 6b: DataTypeContents | "<xsd:any minOccurs=�0� maxOccurs=�u processContents=�" // ProcessCont "�/>")? ("</xsd:choice>" | "</xsd:sequence>")? 4g:ClassAttListItems ( "</xsd:extension>" "</xsd:complexContent>" )? "</xsd:complexType> 6a. DataTypeName ::= 1h:Namespace //Name of DataType// 6b. DataTypeContents ::= 4d: ClassAttributes 4c:Extension 6. These rules describe the declaration of a structured DataType in the metamodel as an XML complex type with a content model and XML attributes. The rules for declaring the Properties are the same as for Classes except that compositions and references do not apply to DataTypes. 6a. This rule is for a reference to the type for the class, which is the name of the DataType prefixed by the namespace, if present and not the default namespace. 6b. The complex type for the DataType contains XML elements for the contained Properties, plus an extension element. The serialize tag can be used to control whether these constructs are serialized. If useSchemaExtensions is false or not present, inherited Attributes are included; otherwise, only local Attributes are included. Proposed Disposition: Resolved
Actions taken:
June 28, 2005: received issue
April 25, 2011: closed issue

Issue 9074: Section: 4.4 (mof2xmi-rtf)

Click here for this issue's archive.
Source: Humboldt-Universitaet (Mr. Martin von Loewis, loewis(at)informatik.hu-berlin.de)
Nature: Revision
Severity: Minor
Summary:

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.

Resolution: This is a duplicate of issue number 10112. Resolve with no change. Disposition: Merged / Duplicate
Revised Text:
Actions taken:
October 4, 2005: received issue
May 27, 2011: closed issue

Discussion:

Issue 9293: section 4.3.1 (Required XML Declarations), (mof2xmi-rtf)

Source: Adaptive (Mr. Gene Mutschler, gene.mutschler(at)adaptive.com)
Nature: Uncategorized Issue
Severity:
Summary:

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.

Resolution: Delete text as described below
Revised Text: Replace the text in the first paragraph of section 4.3.1 which current reads: This specification requires that XML element declarations, types, attributes, and attribute groups be included in schemas to enable XML validation of metadata that conforms to this specification. 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. with: This specification requires that XML element declarations, types, attributes, and attribute groups be included in schemas to enable XML validation of metadata that conforms to this specification.
Actions taken:
January 27, 2006: received issue
May 27, 2011: closed issue

Issue 9294: what, if anything, is normative in XMI 2.1 (mof2xmi-rtf)

Click here for this issue's archive.
Source: Adaptive (Mr. Gene Mutschler, gene.mutschler(at)adaptive.com)
Nature: Uncategorized Issue
Severity:
Summary:

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?

Resolution: XMI Schemas must be equivalent to those generated by the XMI Schema production rules specified in this document. Equivalence means that XMI documents that are valid under a schema produced by the XMI Schema production rules would be valid in a conforming XMI Schema and that those XMI documents that are not valid under a schema produced by the XMI Schema production rules are not valid in a conforming XMI Schema.
Revised Text: XMI Schemas must be equivalent to those generated by the XMI Schema production rules specified in this document. Equivalence means that XMI documents that are valid under a schema produced by the XMI Schema production rules would be valid in a conforming XMI Schema and that those XMI documents that are not valid under a schema produced by the XMI Schema production rules are not valid in a conforming XMI Schema.
Actions taken:
January 27, 2006: received issue
April 25, 2011: closed issue

Issue 9295: section 4.5.3 (mof2xmi-rtf)

Click here for this issue's archive.
Source: Adaptive (Mr. Gene Mutschler, gene.mutschler(at)adaptive.com)
Nature: Uncategorized Issue
Severity:
Summary:

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.

Resolution: The resolution of issue 9650 removes the version attribute, as the XMI version is always included in the XMI namespace URI. This renders this issue obsolete (duplicate). Revised Text: (see resolution of issue 9650) Disposition: Closed � Duplicate to issue 9650
Revised Text:
Actions taken:
January 23, 2006: received issue
May 27, 2011: closed issue

Issue 9296: timestamp attribute (mof2xmi-rtf)

Click here for this issue's archive.
Source: Adaptive (Mr. Gene Mutschler, gene.mutschler(at)adaptive.com)
Nature: Uncategorized Issue
Severity:
Summary:

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.

Resolution: The RTF consider this as a valuable argument
Revised Text: Figure 4.1: Include the following at the end of the list of properties in the Documentation class: timestamp: DateTime [0..1] Add new rectangle to the right of the Figure 4.1 with keyword �primitive� above name DateTime Add the following to the end of paragraph 2 of 4.5.2: The DateTime primitive type has XML Schema data type of �http://www.w3.org/2001/XMLSchema#dateTime.� Include the PrimitiveType �DateTime� in the XMI for the XMI metamodel, with Tag org.omg.xmi.schemaType=�http://www.w3.org/2001/XMLSchema#dateTime.� In section 4.5.5, replace: the version of the tool, and copyright or other legal notices regarding the document. The data type of all the attributes of Documentation is string. By: the version of the tool, the date and time the document was created, and copyright or other legal notices regarding the document. The data type of all the attributes of Documentation is string except for the timestamp which is DateTime. Include the following after the xsd:element name=�owner�: xsd:element name=�timestamp� type=�xsd:datetime�
Actions taken:
January 23, 2006: received issue
April 25, 2011: closed issue

Issue 9396: Section 6.4.1 5j:Extension (mof2xmi-rtf)

Click here for this issue's archive.
Source: KDM Analytics (Dr. Nikolai Mansourov, nick(at)kdmanalytics.com)
Nature: Uncategorized Issue
Severity:
Summary:

   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 ?

Resolution: Replace text as described below
Revised Text: In section 6.4.1 rule 1a currently reads: 1a:XMI ::= "<" 1b:XMINamespace "XMI" 1c:StartAttribs ">" ( 2a:XMIObjectElement)* ( 5j:Extension )* "</" 1b:XMINamespace "XMI>" Replace 5j with 4c to give the following: 1a:XMI ::= "<" 1b:XMINamespace "XMI" 1c:StartAttribs ">" ( 2a:XMIObjectElement)* ( 4c:Extension )* "</" 1b:XMINamespace "XMI>"
Actions taken:
February 13, 2006: received issue
April 25, 2011: closed issue

Issue 9512: Urgent issue on XMI 2.1 -inconsistency between XMI metamodel and quoted XSD (mof2xmi-rtf)

Click here for this issue's archive. Click here for this issue's attachments.
Source: Adaptive (Mr. Pete Rivett, pete.rivett(at)adaptive.com)
Nature: Uncategorized Issue
Severity: Critical
Summary:

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.

Resolution: This issue was resolved in version 2.1.1. Close no change. Disposition: Closed � No Change
Revised Text:
Actions taken:
April 5, 2006: received issue
May 27, 2011: closed issue

Issue 9557: Section: 4.9.3 (mof2xmi-rtf)

Nature: Clarification
Severity: Significant
Summary:

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.

Resolution: This proposed enhancement would break backward compatibility. Close no change. Disposition: Closed � No Change
Revised Text:
Actions taken:
April 12, 2006: received issue
May 27, 2011: closed issue

Issue 9624: Section 4.5.2 (mof2xmi-rtf)

Click here for this issue's archive.
Source: Adaptive (Mr. Pete Rivett, pete.rivett(at)adaptive.com)
Nature: Uncategorized Issue
Severity:
Summary:

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.

Resolution: Replace text as described below
Revised Text: Replace the last 2 sentences in the second paragraph of section 4.5.2which current reads: 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.� with: The String datatype and the Integer datatype come from the PrimitiveTypes package used by MOF Core and UML Infastructure. The PrimitiveTypes package also contains unlimited natural and boolean.
Actions taken:
April 29, 2006: received issue
April 25, 2011: closed issue

Issue 9625: Section 4.5.4 (mof2xmi-rtf)

Click here for this issue's archive.
Source: Adaptive (Mr. Pete Rivett, pete.rivett(at)adaptive.com)
Nature: Uncategorized Issue
Severity:
Summary:

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.

Resolution: Add text as described below
Revised Text: Add text to the third sentence of paragraph 2 of section 4.5.4 which current reads: The extenderID is an optional internal ID from the extending tool. with: The extenderID is an optional internal ID from the extending tool that allows the element to be uniquely located within the tool.
Actions taken:
April 29, 2006: received issue
April 25, 2011: closed issue

Issue 9626: 4.10.3 is an example from UML 1.4 (mof2xmi-rtf)

Click here for this issue's archive.
Source: Adaptive (Mr. Pete Rivett, pete.rivett(at)adaptive.com)
Nature: Uncategorized Issue
Severity:
Summary:

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.

Resolution: The example in 4.12.4 has been updated in the resolution to 9632. The other 2 examples listed need updating.
Revised Text: Rename 4.10.3 to �Example for UML� Replace the following in line 1 of 4.10.3: Operations are a subclass of ModelElements. By: Operation is a subclass of ModelElement. Replace the following in line 2 of 4.10.3: with roles constraint By with roles ownedRule In 4.10.3 replace Document 1 and following content by: Document 1, doc1.xml (omitting root and namespace declarations): <uml:Operation xmi:id="idO1" xmi:type="uml:Operation" xmi:label="op1" xmi:uuid="DCE:1234"> <ownedRule xmi:id="idC1" xmi:type="uml:Constraint" xmi:label="co1" xmi:uuid="DCE:abcd"> <specification xmi:type="uml:OpaqueExpression"> <body>First Constraint definition</body> </specification> <constrainedElement xmi:idref="idO1"/> </ownedRule> <ownedRule xmi:idref="idC2" /> <ownedRule xmi:idref="idC3" /> <ownedRule href="doc2.xml#idC4" /> </uml:Operation> <uml:Constraint xmi:id="idC2" xmi:type="uml:Constraint" xmi:label="co2" xmi:uuid="DCE:efgh"> <specification xmi:type="uml:OpaqueExpression"> <body>Second Constraint definition</body> </specification> <constrainedElement xmi:idref="idO1" /> </uml:Constraint> <uml:Constraint xmi:id="idC3" xmi:type="uml:Constraint" xmi:label="co3" xmi:uuid="DCE:ijkl"> <specification xmi:type="uml:OpaqueExpression"> body>Third Constraint definition</body> </specification> <constrainedElement href="#xpointer(descendent(1,Operation,xmi:label,op1))"/> </uml:Constraint> Replace Document 2 and following content by: Document 2, doc2.xml (omitting root and namespace declarations): <uml:Constraint xmi:id="idC4" xmi:type="uml:Constraint" xmi:label="co4" xmi:uuid="DCE:mnop"> <specification xmi:type="uml:OpaqueExpression"> <body>Fourth Constraint definition</body> </specification> <constrainedElement href="doc1.xml#idO1"/> </uml:Constraint> In 4.9.3 replace The following is an example of an incomplete UML 1.4 model: By: The following is an example of an incomplete UML model (omitting root and namespace declarations): In 4.9.3 replace the content by: <uml:Model xmi:type="uml:Model" name="model1" xmi:id="id1"> <packagedElement xmi:type="uml:Class" name="class1" xmi:id="id2"> <ownedAttribute xmi:type="uml:Property" name="attribute1" type="type1"/> </ownedAttribute> </packagedElement> <packagedElement xmi:type="uml:DataType" name="Number" xmi:id="type1"/> </UML:Model>
Actions taken:
April 29, 2006: received issue
April 25, 2011: closed issue

Issue 9627: 4.10.3, line 4 of the example "Document 1" (mof2xmi-rtf)

Click here for this issue's archive.
Source: Adaptive (Mr. Pete Rivett, pete.rivett(at)adaptive.com)
Nature: Uncategorized Issue
Severity:
Summary:

 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.

Resolution: The issue is wrong: xmi:type was never required for link elements, and from XMI 2.4 it is not even allowed. Revised Text: - none - Disposition: Closed � No Change
Revised Text:
Actions taken:
April 29, 2006: received issue
April 25, 2011: closed issue

Issue 9628: 6.5.3 2nd row of table (mof2xmi-rtf)

Click here for this issue's archive.
Source: Adaptive (Mr. Pete Rivett, pete.rivett(at)adaptive.com)
Nature: Uncategorized Issue
Severity:
Summary:

6.5.3 2nd row of table starts "As Association": this should be "An Association",

Resolution: Replace text as described below
Revised Text: In the table found in section 6.5.3 replace the left side of the last row, which currently reads: As Association, all ends are ownedEnds with: An Association, all ends are ownedEnds
Actions taken:
April 29, 2006: received issue
May 27, 2011: closed issue

Issue 9629: 6.5 should be further clarified (mof2xmi-rtf)

Click here for this issue's archive.
Source: Adaptive (Mr. Pete Rivett, pete.rivett(at)adaptive.com)
Nature: Uncategorized Issue
Severity:
Summary:

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.

Resolution: The resolution to this issue should also reflect that MOF 2.4 is no longer based on Abstractions. Furthermore the rules for Abstractions in section 6.5.1 are all redundant since overridden by those for EMOF and CMOF
Revised Text: Swap sections 6.4 and 6.5. (Original) 6.5 Replace: XMI production rules are defined for elements in the Abstractions, EMOF and CMOF packages in the MOF 2 Core, and for the Abstractions package in the UML Infrastructure Core. The rules for these packages are consistent and build upon each other: the rules for the EMOF package refine the Abstractions rules, and the rules for the CMOF package refine the EMOF rules. By: XMI production rules are defined for elements in UML as constrained by the EMOF and CMOF compliance levels in the MOF 2 Core. The rules for these packages are consistent and build upon each other: the rules for CMOF refine the EMOF rules. Delete (original) section 6.5.1 Abstractions package and renumber the following sections
Actions taken:
April 29, 2006: received issue
May 27, 2011: closed issue

Issue 9630: 2.3.1 the first bullet is very vague (mof2xmi-rtf)

Click here for this issue's archive.
Source: Adaptive (Mr. Pete Rivett, pete.rivett(at)adaptive.com)
Nature: Uncategorized Issue
Severity:
Summary:

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).

Resolution: Modify text as described below.
Revised Text: Replace the first bullet in section 2.3.1 which current reads: The guidelines for using the extension elements suggested in Section 4.5, �XMI Model,� on page 8 and Section 4.11, �Tailoring Schema Production,� on page 25. Tools should place their extended information within the designated extension areas, declare the nature of the extension using the standard XMI elements where applicable, and preserve the extensions of other tools where appropriate. with: The guidelines for using the extension elements suggested in Section 4.5, �XMI Model,� are found on page 8 and in Section 4.11, �Tailoring Schema Production,� on page 25. Tools should place their extended information within elements that are not in the XMI namespace or within elements that have the XMI namespace and a tag name of �Extension�. They should also declare the nature of the extension using the standard XMI elements where applicable, and preserve the extensions of other tools that fall within the XMI namespace.
Actions taken:
April 29, 2006: received issue
April 25, 2011: closed issue

Issue 9631: Figure 4.2 (mof2xmi-rtf)

Click here for this issue's archive.
Source: Adaptive (Mr. Pete Rivett, pete.rivett(at)adaptive.com)
Nature: Uncategorized Issue
Severity:
Summary:

In Figure 4.2 the XMI model references Object (from MOF) which should be MOF::Element

Resolution: Update Figure 4.2
Revised Text: see page 30 of ptc/2010-09-08
Actions taken:
April 29, 2006: received issue
April 25, 2011: closed issue

Issue 9632: logic for use of position attributes in 4.5.6 and 4.12.2 is not clear (mof2xmi-rtf)

Click here for this issue's archive.
Source: Adaptive (Mr. Pete Rivett, pete.rivett(at)adaptive.com)
Nature: Uncategorized Issue
Severity:
Summary:

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.

Resolution: A further problem is that the example for Add in 12.2.4 does not make sense: there is no indication that the new Class should be related to the target via the ownedElement association: the addition should be represented as an ownedElement. And the Replace element is generally problematic in being able to specify both an element to be replaced and a position. Given that the intent was not to change the �content� at all it also seems to be incompatible with various XMI options (e.g. serializing metamodel properties as contained XML elements would not work).
Revised Text: 4.5.6 replace the following text: The Add class represents an addition to a target set of objects in this document or other documents. The position attribute indicates where to place the addition relative to other XML elements. The default, -1, indicates to add the new elements at the end of the target element. The addition attribute refers to the set of objects to be added. Both of these attributes have the tag attribute set to �true.� The Replace class represents the deletion of the target set of objects and the addition of the objects referred to in the replacement attribute. The position attribute indicates where to place the replacement relative to other XML elements. The default, -1, indicates to add the replacing elements at the end of the target element. The replacement attribute refers to the object that will replace the target element. Both of these attributes have the tag attribute set to �true.� The Delete class represents a deletion to a target set of objects in this document or other documents. By: The Add class represents an addition to a target object in this document or other documents. The target is constrained to reference only one object. The position attribute indicates where to place the addition relative to other XML elements of that type within the target. The default, -1, indicates to add the new elements at the end of those elements for the target element. The addition attribute refers to the set of objects to be added. Both of these attributes have the tag attribute set to �true.� The Replace class represents the removal of a target set of objects and the addition of the objects referred to in the replacement attribute. The position attribute indicates where to place the replacements relative to other XML elements of that type within their container (they should all be of the same XML type). The default, -1, indicates to add the new elements at the end of those elements for the target element. The replacement attribute refers to the objects that will replace the target elements. Both of these attributes have the tag attribute set to �true.� Note that, unlike Delete, the replaced elements are only removed from the container not deleted. The Delete class represents a deletion of the target set of objects in this document or other documents. 4.5.6 Replace the following declaration in both the Add and Replace complex types: <xsd:attribute name="position" type="xsd:string" use="optional"/> By <xsd:attribute name="position" type="xsd:integer" use="optional"/> 4.12.2 Replace the following text: Differences must be applied in the order defined. A later difference may refer to information added by a previous difference by linking to its contents. Model integrity requires that all the differences transmitted are applied. The following are the types of differences recognized, the information transmitted, and the changes they represent: � Delete (reference to deleted element): The delete operation refers to a particular element of the old model and specifies a deep removal of the referenced element and all of its contents. � Add (reference to containing element, new element, optional position): The add operation refers to a particular element of the old model and specifies a deep addition. The element and its contents are added. The contents of the new element are added at the optional position specified, the default being as the last element of the contents. The optional position form is based on XPointer's position form. 1 means the first position, -1 means the last position, and higher numbers count across the contents in the specified direction. � Replace (reference to replaced element, replacement element, optional position): This operation deletes the old element but not its contents. The new element and its contents are added at the position of the old element. The original contents of the old element are then added to the contents of the new element at the optional position specified, the default being at the end. By: Differences must be applied in the order defined. A later difference may refer to information added by a previous difference by linking to its contents. Model integrity requires that all the differences transmitted are applied. The following are the types of differences recognized, the information transmitted, and the changes they represent: � Delete (reference to deleted elements): The Delete element refers to particular elements and specifies a deep removal of the referenced elements and all of their contained elements (determined through composite associations) � Add (reference to containing element, new elements, optional position): The Add element refers to a particular element of the old model and specifies a deep addition. The elements and their contents are added at the optional position specified relative to elements of that type within the target element (e.g. packagedElement), the default being at the end. The optional position form is based on XPointer's position form. 1 means the first position, -1 means the last position, and higher numbers count across the contents in the specified direction. � Replace (reference to replaced elements, replacement elements, optional position): This operation removes the old elements from their container (they must all have the same container) but does not delete them. The new elements are added at the specified position within the same container (as per Add). 4.12.3 Replace the following text: The following are the elements used to encode the differences. delete The delete element�s link attributes contain a link to the element to be deleted. add The contents of add is the element to be added. The link attributes contain a link to the element to be deleted and an optional position element. The numbering corresponds to XPointer numbering, where 1 is the first and -1 is the last element. replace The contents of replace is the element to replace the old element with. The attributes contain a link to the element to be replaced and an optional position element for the replacing element's contents. The numbering corresponds to XPointer numbering, where 1 is the first and -1 is the last element. By: The following are the elements used to encode the differences. delete The target element�s link attributes contain a link to the element to be deleted. add The addition attribute of add references the elements to be added, which must all be of the same XML type. The target element�s link attributes contain a link to the single container element for the new ones and an optional position. The numbering corresponds to XPointer numbering, where 1 is the first and -1 is the last element and it is used to count the elements of the same type as the ones to be added within the container. The type used is that of the XML element (which typically represents a composite property) as opposed to the xmi:type. The new elements are positioned after the element with the indicated position. replace The target of replace is the set of elements to be replaced which must all be of the same XML type and have the same container. The replacement attribute of replace references the elements to be added to that container, and must again all be of the same XML type. The optional position attribute uses numbering corresponding to XPointer numbering, where 1 is the first and -1 is the last element and it is used to count the elements of the same type as the ones to be added within the container (after removal of the target elements). The type used is that of the XML element (which typically represents a composite property) as opposed to the xmi:type. The new elements are positioned after the element with the indicated position Replace the whole of 4.12.4 with a more up-to-date and useful example: 4.12.4 Example This example will delete a class and its attributes, add two classes, and replace a class within a package. The original document, called original.xml: <xmi:XMI xmlns:uml="https://www.omg.org/spec/UML/20100101" xmlns:xmi=" https://www.omg.org/spec/UML/20100101"> <uml:Package xmi:id="ppp" xmi:label="p1"> <packagedElement xmi:type="uml:Class" xmi:id="ccc" name="c1"> <ownedAttribute xmi:type="uml:Property" name="a1"/> <ownedAttribute xmi:type="uml:Property " name ="a2"/> </packagedElement > </uml:Package> </xmi:XMI> The differences document: <xmi:XMI xmlns:uml="https://www.omg.org/spec/UML/20100101" xmlns:xmi=" https://www.omg.org/spec/UML/20100101"> <difference xmi:type="xmi:Delete"> <target href="original.xml#ccc"/> </difference/> <difference xmi:type="xmi:Add" addition="Class_1 Class_2"> <target href="original.xml#ppp"/> </difference> <packagedElement xmi:type="uml:Class" xmi:id="Class_1" name="c2"> <packagedElement xmi:type="uml:Class" xmi:id="Class_2" name="c3"> <difference xmi:type="xmi:Replace" position="0" replacement="c4"> <target href="original.xml#Class_2"/> </difference> <packagedElement xmi:type="uml:Class" xmi:id="Class_3" name="c4"> </xmi:XMI> Here�s how the 3 differences change the document as they�re applied. The delete: <xmi:XMI xmlns:uml="https://www.omg.org/spec/UML/20100101" xmlns:xmi=" https://www.omg.org/spec/UML/20100101"> <uml:Package xmi:id="ppp" xmi:label="p1"> </uml:Package> </xmi:XMI> Next, the add: <xmi:XMI xmlns:uml="https://www.omg.org/spec/UML/20100101" xmlns:xmi=" https://www.omg.org/spec/UML/20100101"> <uml:Package xmi:id="ppp" xmi:label="p1"> <packagedElement xmi:type="uml:Class" xmi:id="Class_1" name="c2"> <packagedElement xmi:type="uml:Class" xmi:id="Class_2" name="c3"> </uml:Package> </xmi:XMI> Finally, the replace: <xmi:XMI xmlns:uml="https://www.omg.org/spec/UML/20100101" xmlns:xmi=" https://www.omg.org/spec/UML/20100101"> <uml:Package xmi:id="ppp" xmi:label="p1"> <packagedElement xmi:type="uml:Class" xmi:id="Class_3" name="c4"> <packagedElement xmi:type="uml:Class" xmi:id="Class_1" name="c2"> </uml:Package> <uml:Class xmi:type="uml:Class" xmi:id="Class_2" name="c3"> </xmi:XMI> Note that Class_2 is not deleted but merely removed from the package ppp.
Actions taken:
April 29, 2006: received issue
April 25, 2011: closed issue

Issue 9633: XSD fragment for difference elements in 4.5.6 (mof2xmi-rtf)

Click here for this issue's archive.
Source: Adaptive (Mr. Pete Rivett, pete.rivett(at)adaptive.com)
Nature: Uncategorized Issue
Severity:
Summary:

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).

Resolution: The issue refers only to the XML attribute form of target: and forgets that there is also an XML element which allows the use of href or xmi:idref via the inclusion of ObjectAttribs. Revised Text: - none- Disposition: Closed � No Change
Revised Text:
Actions taken:
April 29, 2006: received issue
May 27, 2011: closed issue

Issue 9634: differences section 4.5 should refer to 4.12 (mof2xmi-rtf)

Click here for this issue's archive.
Source: Adaptive (Mr. Pete Rivett, pete.rivett(at)adaptive.com)
Nature: Uncategorized Issue
Severity:
Summary:

The differencs section 4.5 should refer to 4.12 for how the differences are to be processed

Resolution: Add text as described below
Revised Text: Add text to the forth paragraph in section 4.5.6 which current reads: The Difference class is the superclass for the Add, Replace, and Delete classes. with: The Difference class is the superclass for the Add, Replace, and Delete classes (see figure 4.2 and section 4.12).
Actions taken:
April 29, 2006: received issue
April 25, 2011: closed issue

Issue 9635: 2.3.3 is unclear as to what's needed for conformance (mof2xmi-rtf)

Click here for this issue's archive.
Source: Adaptive (Mr. Pete Rivett, pete.rivett(at)adaptive.com)
Nature: Uncategorized Issue
Severity:
Summary:

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".

Resolution: This compliance clause refers to things outside the scope of the MOF XMI Mapping.
Revised Text: Delete clause 2.3.3.
Actions taken:
April 29, 2006: received issue
April 25, 2011: closed issue

Issue 9636: 3.1 refers to 'XML Production of XML Schema' (mof2xmi-rtf)

Click here for this issue's archive.
Source: Adaptive (Mr. Pete Rivett, pete.rivett(at)adaptive.com)
Nature: Uncategorized Issue
Severity:
Summary:

3.1 refers to 'XML Production of XML Schema' which was the name of an RFP/submission but not a formal specification

Resolution: Delete text as described below
Revised Text: Replace the text in section 3.1 which current reads: The technical specification is presented in the main body of this document. It represents a minor revision to XMI 2.0, as defined in XMI Production of XML Schema. with: The technical specification is presented in the main body of this document.
Actions taken:
April 29, 2006: received issue
April 25, 2011: closed issue

Issue 9638: 4.3.3: in the following sentence the word 'lax' should be bold (mof2xmi-rtf)

Click here for this issue's archive.
Source: Adaptive (Mr. Pete Rivett, pete.rivett(at)adaptive.com)
Nature: Uncategorized Issue
Severity:
Summary:

4.3.3: in the following sentence the word 'lax' should be bold. "The processContents attribute is lax,"

Resolution: Bold the word lax in the text as described below.
Revised Text: Bold the text of the word lax in the forth sentence of section 4.3.3 which current reads: The processContents attribute is lax, which means that processors will validate the elements in the extension if a schema is available for them, but will not report an error if there is no schema for them. with: The processContents attribute is lax, which means that processors will validate the elements in the extension if a schema is available for them, but will not report an error if there is no schema for them.
Actions taken:
April 29, 2006: received issue
April 25, 2011: closed issue

Issue 9639: Section 4.3.1 (mof2xmi-rtf)

Click here for this issue's archive.
Source: Adaptive (Mr. Pete Rivett, pete.rivett(at)adaptive.com)
Nature: Uncategorized Issue
Severity:
Summary:

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.

Resolution: This is a duplicate of issue number 9293. Resolve with no change. Disposition: Merged / Duplicate
Revised Text:
Actions taken:
April 29, 2006: received issue
May 27, 2011: closed issue

Issue 9640: Section 4.3.3 (mof2xmi-rtf)

Click here for this issue's archive.
Source: Adaptive (Mr. Pete Rivett, pete.rivett(at)adaptive.com)
Nature: Uncategorized Issue
Severity:
Summary:

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.

Resolution: Delete text as described below
Revised Text: Delete words in the last two sentences of the first paragraph of section 4.3.3 which current reads: 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. with: One use of the extension mechanism might be to transmit data that represents extensions to a model.
Actions taken:
April 29, 2006: received issue
April 25, 2011: closed issue

Issue 9641: Section 4.4 (mof2xmi-rtf)

Click here for this issue's archive.
Source: Adaptive (Mr. Pete Rivett, pete.rivett(at)adaptive.com)
Nature: Uncategorized Issue
Severity:
Summary:

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."

Resolution: Add text as described below
Revised Text: Add text in the first sentence of section 4.5.3 which current reads: The top level XML element for XMI documents containing only XMI data is the XMI element. with: The root XML element for XMI documents containing only XMI data may be the XMI element, but it must be the XMI element if there are multiple elements.
Actions taken:
April 29, 2006: received issue
April 25, 2011: closed issue

Issue 9642: Section 4.5.1 (mof2xmi-rtf)

Click here for this issue's archive.
Source: Adaptive (Mr. Pete Rivett, pete.rivett(at)adaptive.com)
Nature: Uncategorized Issue
Severity:
Summary:

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."

Resolution: Replace the last sentence in the first paragraph of section 4.5.1which current reads: The version of this XMI specification is 2.1, and its XMI namespace is �http://schema.omg.org/spec/XMI/2.1.� with: The version of this XMI specification is 2.1.1, and its XMI namespace is �http://schema.omg.org/spec/XMI/2.1.1", and the XSD file can be found at "http://schema.omg.org/spec/XMI/20071001/07-10-06.xsd."
Revised Text:
Actions taken:
April 29, 2006: received issue
April 25, 2011: closed issue

Discussion:

Replace text as described below

Issue 9643: 4.6.1: should descrieb what importer is expected to do with label attribute (mof2xmi-rtf)

Click here for this issue's archive.
Source: Adaptive (Mr. Pete Rivett, pete.rivett(at)adaptive.com)
Nature: Uncategorized Issue
Severity:
Summary:

.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.

Resolution: Ignore the label.
Revised Text: Add the following to the description of label in 4.6.1: The value of the label attribute is ignored on import.
Actions taken:
April 29, 2006: received issue
May 27, 2011: closed issue

Issue 9644: 4.6.1, and elsewhere (mof2xmi-rtf)

Click here for this issue's archive.
Source: Adaptive (Mr. Pete Rivett, pete.rivett(at)adaptive.com)
Nature: Uncategorized Issue
Severity:
Summary:

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.

Resolution: Change as recommended, though these Property::isId and Package::uri are in UML2.4 now. Note: this change must be applied to sections 4.6.2, 5.2.2 and the XMI.xsd file.
Revised Text: In section �4.6.1, subsection labeled with �id�, replace the second paragraph, reading: The org.omg.xmi.idProperty tag can be used to nominate a property of a class to be class�s id. In this case, the property is declared in the XML Schema with a type of xsd:ID, and no additional id attribute is serialized for objects that are instances of this class. The nominated property must be a Datatype. By: If the metaclass has (or inherits) a Property with isId = �true� then the value of that property may be used as the basis of the xmi:id and/or xmi:uuid attributes. This is not mandatory, and the exact algorithm to be used is not specified in this specification. However it is important, to be a valid XML document, that the value for xmi:id is unique across all elements within the file. The xmi:uuid is not so constrained, but if the same value is used in multiple XML elements then they are all deemed to reference the same MOF element (e.g. they may represent different aspects). In tables 4.1 and 4.2, delete the rows defining the org.omg.xmi.idProperty and org.omg.xmi.idName tags. In section 4.11.2, delete the last bullet point, reading: If the idProperty tag is true, the idName tag is ignored. The tagged property must have type Datatype. Only one idProperty tag may be specified for a class. In section 6.4.2, replace rule 2f, reading: 2f:IdAttribName ::= xmiPrefix "id" | xmiIdAttribName By 2f:IdAttribName ::= �xmi:id� In section 6.4.2, replace the description of rule 2f, reading: By default, the name of the identity attribute is �id� in the XMI namespace. However, if an org.omg.xmi.idName tag has been specified, the name of the identity attribute is the value of that tag. If an org.omg.xmi.idProperty tag has been specified, that property will be used as the id, and the standard XMI id will not be written. By: The name of the identity attribute is �id� in the XMI namespace.
Actions taken:
April 29, 2006: received issue
April 25, 2011: closed issue

Issue 9645: 4.6.1: uuid should refer to the use of URIs (mof2xmi-rtf)

Click here for this issue's archive.
Source: Adaptive (Mr. Pete Rivett, pete.rivett(at)adaptive.com)
Nature: Uncategorized Issue
Severity:
Summary:

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.

Resolution: The MOF Facility and Object Lifecycle specification provides detailed instructions how to generate URIs to be used as uuids.
Revised Text: In section 4.6.1, replace the following text: The purpose of this attribute is to provide a globally unique identifier for an XML element. The values of this attribute should be globally unique strings prefixed by the type of identifier. If you have access to the UUID assigned in MOF, you may put the MOF UUID in the uuid XML attribute when encoding the MOF data in XMI. For example, to include a DCE UUID as defined by The Open Group, the UUID would be preceded by �DCE:.� The values of this attribute may be used in the href attribute in simple XLinks. XMI does not specify which UUID convention is chosen. The form of the UUID (Universally Unique Identifier) is taken from a standard defined by the Open Group (was Open Software Foundation). This standard is widely used, including by Microsoft for COM (GUIDs) and by many companies for DCE, which is based on CORBA. The method for generating these 128-bit IDs is published in the standard and the effectiveness and uniqueness of the IDs is not in practice disputed. When a UUID is placed in an XMI file, the form is �id namespace:uuid.� The id namespace of UUIDs is typically DCE. An example is �DCE:2fac1234-31f8-11b4-a222-08002b34c003.� By the following text: The purpose of this attribute is to provide a globally unique identifier for an XML element. The values of this attribute should be globally unique strings prefixed by the type of identifier. If you have access to the UUID assigned in MOF, you may put the MOF UUID in the uuid XML attribute when encoding the MOF data in XMI. UUIDs should use URIs as the unique string. Refer to section 6.4.1.1 of the MOF Facility and Object Lifecycle Specification for an example of a scheme for detailed URI production rules. An example URI for the metaclass UseCase in the UML2 metamodel looks like this: http://mof.omg.org/MetamodelFacility/UML2Store?uml2/UseCase
Actions taken:
April 29, 2006: received issue
April 25, 2011: closed issue

Issue 9646: Section 4.5.3 (mof2xmi-rtf)

Click here for this issue's archive.
Source: Adaptive (Mr. Pete Rivett, pete.rivett(at)adaptive.com)
Nature: Uncategorized Issue
Severity:
Summary:

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."

Resolution: Delete the 7th paragraph in section 4.5.3, which currently begins with the words �The serialization of the XMI element ��.
Revised Text: Delete the 7th paragraph in section 4.5.3, which currently begins with the words �The serialization of the XMI element ��.
Actions taken:
April 29, 2006: received issue
April 25, 2011: closed issue

Issue 9647: 4.5.3: the tag settings should include 'org.omg.xmi.attribute' = false (mof2xmi-rtf)

Click here for this issue's archive.
Source: Adaptive (Mr. Pete Rivett, pete.rivett(at)adaptive.com)
Nature: Uncategorized Issue
Severity:
Summary:

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

Resolution: Add text as described below
Revised Text: Add the following bullet to the end of the list at the top of page 11: ? tag attribute set to "false"
Actions taken:
April 29, 2006: received issue
April 25, 2011: closed issue

Issue 9648: end of 4.6.1 (mof2xmi-rtf)

Click here for this issue's archive.
Source: Adaptive (Mr. Pete Rivett, pete.rivett(at)adaptive.com)
Nature: Uncategorized Issue
Severity:
Summary:

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.

Resolution: The refID() function is from MOF 1.x and does no .longer exist in MOF 2.
Revised Text: In section 4.6.1, delete the last sentence which reads �The MOF refID() is often used as the uuid in XMI implementations.�.
Actions taken:
April 29, 2006: received issue
April 25, 2011: closed issue

Issue 9649: Section 4.6.2 (mof2xmi-rtf)

Click here for this issue's archive.
Source: Adaptive (Mr. Pete Rivett, pete.rivett(at)adaptive.com)
Nature: Uncategorized Issue
Severity:
Summary:

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.

Resolution: The need to define normative references, as required by this issue, highlighted the inconsistency of the front parts of the document with the formal structure needed by ISO.
Revised Text: Delete current section 3.1 which consists solely of the redundant: The technical specification is presented in the main body of this document. It represents a minor revision to XMI 2.0, as defined in XMI Production of XML Schema. Renumber Section 3 to 6 and section 3.2 to 6.1 Add a new Section 3 as follows: 3. Normative References The following normative documents contain provisions which, through reference in this text, constitute provisions of this specification. For dated references, subsequent amendments to, or revisions of, any of these publications do not apply. � Extensible Markup Language (XML) 1.0 (Fifth Edition) W3C Recommendation 26 November 2008 � XML Schema Part 1: Structures Second Edition W3C Recommendation 28 October 2004 � XML Schema Part 2: Datatypes Second Edition W3C Recommendation 28 October 2004 � XML Linking Language (XLink) Version 1.1 W3C Recommendation 06 May 2010 � XPointer Framework W3C Recommendation 25 March 2003 � XPointer element() Scheme W3C Recommendation 25 March 2003 � XPointer xmlns() Scheme W3C Recommendation 25 March 2003 Add a new section 4 4 Terms and Definitions There are no formal definitions in this specification that are taken from other documents Add a new section 5 5 Symbols There are no symbols defined in this specification.
Actions taken:
April 29, 2006: received issue
April 25, 2011: closed issue

Issue 9650: Section 4.6.3 (mof2xmi-rtf)

Click here for this issue's archive.
Source: Adaptive (Mr. Pete Rivett, pete.rivett(at)adaptive.com)
Nature: Uncategorized Issue
Severity:
Summary:

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.

Resolution: The authoritative XMI version number is part of the namespace URI. Therefore the version attribute is redundant and might even introduce wrong information. Remove the version attribute from the whole specification
Revised Text: In section �4.5.2 XMI Model classes�: Remove the property version : String[0..1] from class XMI. (change diagram) In section �4.5.3 XMI�, from the definition of <xsd:complexType name="XMI"> Remove the lines reading: <xsd:attribute name="version" type="xsd:string" use="optional" form="qualified"/> Replace the first text paragraph immediately following this complex type definition, starting with �If the XMI version attribute is included�� With the following paragraph: Each version of XMI is unambiguously identified by its unique namespace URI of the form �http://schema.omg.org/spec/XMI/version�. Replace the paragraph starting with �Since the XMI model is an instance of MOF,�� With the following paragraph: 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. The xmi:version attribute is used to denote the start of XMI information and identify the XMI version, when the XMI element itself is not present. Chapter 8 contains examples of the use of the XMI element. The XMI class has the XMI tag contentType set to �any� to indicate that any XMI element may be present in the XMI stream. The XMI version attribute has following XMI tag settings: form is set to �qualified,� attribute is set to �true,� and enforceMinimumMultiplicity set to �true.� 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.
Actions taken:
April 29, 2006: received issue
April 25, 2011: closed issue

Issue 9651: type attribute should always be required in serialized elements. (mof2xmi-rtf)

Click here for this issue's archive.
Source: Adaptive (Mr. Pete Rivett, pete.rivett(at)adaptive.com)
Nature: Uncategorized Issue
Severity:
Summary:

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"/>

Resolution: This is a duplicate of issue 12859. Close no change. Disposition: Merged / Duplicate
Revised Text:
Actions taken:
April 29, 2006: received issue
May 27, 2011: closed issue

Discussion:

Issue 9652: 4.8.1 has "the schema generator must choose ... (mof2xmi-rtf)

Click here for this issue's archive.
Source: Adaptive (Mr. Pete Rivett, pete.rivett(at)adaptive.com)
Nature: Uncategorized Issue
Severity:
Summary:

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.

Resolution: There is no �choice� � the schema generator is obligated to use the URI specified by the mandatory org.omg.xmi.nsURI tag.
Revised Text: In section 4.8.1, replace the first paragraph, reading: When the official schema for a model is produced, the schema generator must choose one or more namespace URIs that uniquely identify the XML namespaces in the model. XML processors will use those namespace URIs to identify the schemas to use for XML validation, as described in the XML schema specification. By: When the official schema for a model is produced, the schema generator must use the namespace URI specified by the Package::URI property on the package representing the metamodel, which may be overridden by the org.omg.xmi.nsURI tag to uniquely identify the XML namespace in the model. XML processors will use namespace URIs to identify the schemas to be used for XML validation, as described in the XML schema specification. In the third paragraph, replace: http://schema.omg.org/spec/UML/1.4 By: https://www.omg.org/spec/UML/20100901 to be consistent with the given example. In section 4.11.1, Table 1, add the following as the Default value for nsURI: Package::URI In section 4.11.1, Table 1, add the following as the Default value for nsPrefix: Package::name
Actions taken:
April 29, 2006: received issue
April 25, 2011: closed issue

Issue 9653: frequent mentions of MOF attributes and references as opposed to properties (mof2xmi-rtf)

Click here for this issue's archive.
Source: Adaptive (Mr. Pete Rivett, pete.rivett(at)adaptive.com)
Nature: Uncategorized Issue
Severity:
Summary:

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

Resolution: Clarify as proposed
Revised Text: In section 4.8.1, replace the paragraph: The XML element name for each model class, package, and association in a document is its short name. The name for XML tags corresponding to model attributes and references is the short name of the attribute or reference. The name of XML attributes corresponding to model references and model attributes is the short name of the reference or attribute, since each tag in XML has its own namespace. By: The XML element name for each model Class and Association in a document is its short name. The name for XML tags corresponding to model Properties is the short name of the property. The name of XML attributes corresponding to model properties (DataType-typed or Class-typed) is the short name of the property, since each tag in XML has its own namespace. Rename section 4.8.4 Property Representation to 4.8.4 DataType-typed Property Representation Rename section 4.8.5 Reference Representation to 4.8.5 Class-typed Property Representation In section 4.8.5, replace the first paragraph reading: A property can reference another object. Each reference is represented in an XML element and/or an XML attribute. The XML element declaration for a property named �r� for a class �c� of type �classType� is: By: A Class-typed property references another model element. Each such reference is represented as an XML element and/or an XML attribute. The XML element declaration for a property named �r� for a class �c� is: In section 4.8.6, replace association roles by Class-typed properties. In section 4.8.8, replace AssociationEnds with reference by Class-typed properties. In section 4.11.4, first sentence, replace (MOF attribute or reference) by (DataType-typed or Class-typed properties) And in the bulleted list following XML element only, replace: is a multi-valued attribute, or by is a multi-valued property, or replace: is an attribute whose type is not a simple data type. by is a property whose type is not a simple data type. In section 4.11.5, replace the paragraph after the first bulleted list and immediately before table 4.2 with the following paragraph: By setting a tag on a Package or Class, you avoid setting the same tags repeatedly for Classes in the Package, and for Properties belonging to the Class. For example, the element tag applies to Properties. If the element tag is set to true for a Class, the Class itself is not affected, but each Property belonging to the Class is treated as if the element tag were set to true for all of them. In section 5.2, description of rule 3, replace attributes and references by properties, so that the rule description reads: 3. The class schema contribution consists of a type declaration based on the Properties of the Class, and an element declaration for the Class itself. In section 5.2, replace the description of rule 4b with the following text: The complexType for the Class contains XML elements for the contained DataType-typed and Class-typed properties and Compositions of the Class, plus an extension element, regardless of whether they are marked as derived. The org.omg.xml.serialize tag can be used to control whether these constructs are serialized. If org.omg.xml.useSchemaExtensions is false or not present, inherited DataType-typed and Class-typed properties, and Compositions are included; otherwise, only local DataType-typed and Class-typed properties, and Compositions are included. In section 5.2, replace the description of rule 4d with the following text: The XML element name for each DataType-typed property of the Class is listed as part of the content model of the Class element. This includes the DataType-typed properties defined for the Class itself as well as all of the DataType-typed properties inherited from superclasses of the Class. The type is �xsd:string� for simple properties, the name of an enumeration for enumerated properties, or the value of the schemaType tag, if present. For complex properties (possible in CMOF only), when useSchemaExtensions is true, the name of the property type is used from rule 4, and when useSchemaExtensions is false, xmi:Any is used. If the includeNils tag is false, then the �nillable� property is not included in the declaration. If enforceMinimumMultiplicity is true, the minOccurs attribute is included. If enforceMaximumMultiplicity is true, the maxOccurs attribute is included. Following the pattern demonstrated in the above corrections to production rules descriptions, apply the following to all remaining production rule descriptions in this section: Replace occurrences of Attribute with DataType-typed property; replace occurrences of Reference with Class-typed property; replace occurrences of attribute, when referencing class attributes (in contrast to XML attributes) with property; replace occurrences of reference, when referencing to references (associations) between classes (in contrast to XML references) with property; replace occurrences of AssociationEnd with Class-typed property; replace occurrences of association role with Class-typed property. Apply this pattern of changes also to the descriptions of production rules in section 6.5.
Actions taken:
April 29, 2006: received issue
April 25, 2011: closed issue

Issue 9654: Statement in section 4.8.1 (mof2xmi-rtf)

Click here for this issue's archive.
Source: Adaptive (Mr. Pete Rivett, pete.rivett(at)adaptive.com)
Nature: Uncategorized Issue
Severity:
Summary:

4.8.1 states "each tag in XML has its own namespace." which is not technically correct - 'naming context' would be btter than 'namespace'

Resolution: Change as proposed
Revised Text: In section 4.8.1, second paragraph, last sentence: Change the last word �namespace� to �naming context�, so that the end of the last sentence reads: �� since each tag in XML has its own naming context.�
Actions taken:
April 29, 2006: received issue
April 25, 2011: closed issue

Issue 9655: 4.8.1 The example should be made consistent (mof2xmi-rtf)

Click here for this issue's archive.
Source: Adaptive (Mr. Pete Rivett, pete.rivett(at)adaptive.com)
Nature: Uncategorized Issue
Severity:
Summary:

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)

Resolution: Correct the example.
Revised Text: In section 4.8.1, replace the example by the following: <xmi:XMI xmlns:uml="https://www.omg.org/spec/UML/20100901" xmlns:xmi=" https://www.omg.org/spec/XMI/20100901"> <uml:Class name="C1" xmi:type=�uml:Class� xmi:id="_1" > <ownedAttribute xmi:type="uml:Property" xmi:id="_2" name="a1" visibility="private"/> </uml:Class> </xmi:XMI>
Actions taken:
April 29, 2006: received issue
April 25, 2011: closed issue

Issue 9656: XMI element is optional (mof2xmi-rtf)

Click here for this issue's archive.
Source: Adaptive (Mr. Pete Rivett, pete.rivett(at)adaptive.com)
Nature: Uncategorized Issue
Severity:
Summary:

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.

Resolution: Since the top-level element is not necessarily the XMI element, replace �XMI� with �top level�.
Revised Text: In section 4.8.1, third paragraph, second sentence: Replace �XMI� by �top level�, so that the sentence reads: �The logical URI is placed in the namespace declaration of the top level element in XML documents that contain instances of the model.�
Actions taken:
May 10, 2006: received issue
April 25, 2011: closed issue

Issue 9657: Statement in section 4.8.2 (mof2xmi-rtf)

Click here for this issue's archive.
Source: Adaptive (Mr. Pete Rivett, pete.rivett(at)adaptive.com)
Nature: Uncategorized Issue
Severity:
Summary:

4.8.2 states "By default, XMI produces schemas that ignore multiplicities also." This should refer to "XMI 2".

Resolution: Change as proposed
Revised Text: In section 4.8.2, first paragraph, second sentence: Change �XMI� to �XMI 2�, so that the sentence reads: �By default, XMI 2 produces schemas that ignore multiplicities also.�
Actions taken:
April 29, 2006: received issue
April 25, 2011: closed issue

Issue 9658: Statement in section 4.8.4 (mof2xmi-rtf)

Click here for this issue's archive.
Source: Adaptive (Mr. Pete Rivett, pete.rivett(at)adaptive.com)
Nature: Uncategorized Issue
Severity:
Summary:

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...".

Resolution: Replace text as described below
Revised Text: Replace the text of the first 3 sentences in section 4.8.4 which current reads: The representation of properties of class �c� uses XML elements and XML attributes. If the property types are primitives or enumerations, 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 attributes, and may have poor control of whitespace processing with options that apply only to element contents. with: The representation of properties of class �c� uses XML elements and XML attributes. If the property types are primitives or enumerations, then by default both XML attributes and XML elements are declared for these types. The reasons for the XML element choice are several, including: the values to be exchanged may be very large values and unsuitable for XML attributes, and may have poor control of whitespace processing with options that apply only to element contents.
Actions taken:
April 29, 2006: received issue
April 25, 2011: closed issue

Issue 9659: Section 4.8.4 editorial (mof2xmi-rtf)

Click here for this issue's archive.
Source: Adaptive (Mr. Pete Rivett, pete.rivett(at)adaptive.com)
Nature: Uncategorized Issue
Severity:
Summary:

4.8.4 has "For properties whose types are primitive types (for example, string)". The last word should be String (capital S).

Resolution: Replace text as described below
Revised Text: Replace the text of the first part of the first sentence in the forth paragraph of section 4.8.4 which current reads: For properties whose types are primitive types (for example, string) with: For properties whose types are MOF primitive types (for example, String)
Actions taken:
April 29, 2006: received issue
April 25, 2011: closed issue

Issue 9660: Section 4.8.4 issue (mof2xmi-rtf)

Click here for this issue's archive.
Source: Adaptive (Mr. Pete Rivett, pete.rivett(at)adaptive.com)
Nature: Uncategorized Issue
Severity:
Summary:

 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."

Resolution: Replace text as described below
Revised Text: Replace the text of the last part of the seventh paragraph of section 4.8.4 which current reads: where enumName is the name of the enumeration type, and v1 and v2 are the enumeration literals. with: where enumName is the name of the Enumeration, and v1 and v2 are the names of the EnumerationLiterals
Actions taken:
April 29, 2006: received issue
April 25, 2011: closed issue

Issue 9661: 4.8.4 (mof2xmi-rtf)

Click here for this issue's archive.
Source: Adaptive (Mr. Pete Rivett, pete.rivett(at)adaptive.com)
Nature: Uncategorized Issue
Severity:
Summary:

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).

Resolution: Follow proposal and remove the �with caution provision� and remove tag org.omg.xmi.defaultValue. Furthermore the org.omg.org.fixedValue tag is pointless � it was only ever used for xmi:version which has been deleted by another resolution.
Revised Text: In section 4.8.4, near the end of the section, locate the paragraph starting with: �For properties with default values, the default value ��. Replace the whole paragraph, bullets and Note (up to the end of the section) with the following text: The semantics of default values differs between MOF/UML and XML Schema, so the XML Schema will never contain default values for Properties. Delete tag �org.omg.xmi.defaultValue� from table 4.1 and 4.2. Delete tag �org.omg.xmi.fixedValue� from table 4.1 and 4.2. In section 5.2.1, change rules 4j and 4k to remove the default and fixed options, becoming: 4j. ClassAttribData ::= "<xsd:attribute name=�" //Name of attribute// "�" "type=�xsd:string� " ("use=�optional�" | "use=�required�") ("form=�" // Form value // "�")? "/>" 4k. ClassAttribEnum ::= "<xsd:attribute name=�" //Name of attribute// "�" "type=�" 8a:EnumTypeName "�" ("use=�optional�" | "use=�required�") "/>" In section 5.2.1delete rules 4l and 4o and their descriptions
Actions taken:
April 29, 2006: received issue
April 25, 2011: closed issue

Issue 9662: Clarification in section 4.8.17 (mof2xmi-rtf)

Click here for this issue's archive.
Source: Adaptive (Mr. Pete Rivett, pete.rivett(at)adaptive.com)
Nature: Uncategorized Issue
Severity:
Summary:

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.

Resolution: Resolution included in resolution to 8884. In addition, change the one sentence mentioned in the issue.
Revised Text: In Section 4.8.7, after the XMI snippet, change the sentence: In the instance document, the value of the datatype appears as character content. To: In the instance document, the value of a simple datatype appears as an attribute value or as character content.
Actions taken:
April 29, 2006: received issue
April 25, 2011: closed issue

Issue 9663: Sections 4.8.l7, 6.5.3.1: syntax proposed is unusable (mof2xmi-rtf)

Click here for this issue's archive.
Source: Adaptive (Mr. Pete Rivett, pete.rivett(at)adaptive.com)
Nature: Uncategorized Issue
Severity:
Summary:

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>

Resolution: Resolved by the resolution to issue 8884. Revised Text: (see resolution to issue 8884) Disposition: Closed � Duplicate to issue 8884
Revised Text:
Actions taken:
April 29, 2006: received issue
May 27, 2011: closed issue

Issue 9664: Section 4.8.8 (mof2xmi-rtf)

Click here for this issue's archive.
Source: Adaptive (Mr. Pete Rivett, pete.rivett(at)adaptive.com)
Nature: Uncategorized Issue
Severity:
Summary:

4.8.8 Should say "more control to the metamodeler" rather than "to the end user"

Resolution: Section 4.8.9, not 4.8.8. Change as proposed.
Revised Text: In section 4.8.9, third sentence: Replace �end users� with �metamodelers�, so that the sentence reads: �This capability provides more control to the metamodelers, allowing them ��
Actions taken:
April 29, 2006: received issue
April 25, 2011: closed issue

Issue 9665: xmi:type (mof2xmi-rtf)

Click here for this issue's archive.
Source: Adaptive (Mr. Pete Rivett, pete.rivett(at)adaptive.com)
Nature: Uncategorized Issue
Severity:
Summary:

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

Resolution: Extend the last sentence of the first paragraph in the spirit proposed
Revised Text: In section 4.8.8, first paragraph, last sentence: Extend this sentence at its end by a comma, followed by: �and therefore uses xmi:type instead of xsi:type.�
Actions taken:
April 29, 2006: received issue
April 25, 2011: closed issue

Issue 9666: Statement in section 4.9 (mof2xmi-rtf)

Click here for this issue's archive.
Source: Adaptive (Mr. Pete Rivett, pete.rivett(at)adaptive.com)
Nature: Uncategorized Issue
Severity:
Summary:

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

Resolution: Replace text as described below
Revised Text: Replace the last sentence in the first paragraph after the last bullet after the first example in section 4.9 which current reads: In XMI 2, a schema generator can decide whether to support the exchange of model fragments. with: Starting with XMI version 2.0, an implementation can decide whether to support the exchange of model fragments.
Actions taken:
April 29, 2006: received issue
April 25, 2011: closed issue

Issue 9667: issue with section 4.10.1 (mof2xmi-rtf)

Click here for this issue's archive.
Source: Adaptive (Mr. Pete Rivett, pete.rivett(at)adaptive.com)
Nature: Uncategorized Issue
Severity:
Summary:

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?

Resolution: Delete text as described below
Revised Text: Delete the last sentence in the fifth bullet of section 4.10.1 which current reads: 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. with: 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
Actions taken:
April 29, 2006: received issue
April 25, 2011: closed issue

Issue 9668: 4.10.1 the following bullet is misleading (mof2xmi-rtf)

Click here for this issue's archive.
Source: Adaptive (Mr. Pete Rivett, pete.rivett(at)adaptive.com)
Nature: Uncategorized Issue
Severity:
Summary:

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

Resolution: Replace text as described below
Revised Text: Replace the sixth bullet in section 4.10.1 which current reads: 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. with: When acting as a proxy, XML attributes may be defined, but not contents. The XML attributes act as a cache or guide that gives an indication if the link should be followed: however there is no guarantee that these cached values accurately represent the current values of the linked element.
Actions taken:
April 29, 2006: received issue
April 25, 2011: closed issue

Issue 9669: Addition to section 4.10.1 (mof2xmi-rtf)

Click here for this issue's archive.
Source: Adaptive (Mr. Pete Rivett, pete.rivett(at)adaptive.com)
Nature: Uncategorized Issue
Severity:
Summary:

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."

Resolution: Add text as described below
Revised Text: Add text to the ninth bullet of section 4.10.1 which current reads: 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. with: It is efficient practice to use local proxies of the same element within a document to link to a single proxy that holds an external reference. For example: there could be local proxies defined for references to the predefined DataTypes such as Integer, UnlimitedNatural, String, and Boolean.
Actions taken:
April 29, 2006: received issue
April 25, 2011: closed issue

Issue 9670: Section 4.10.1 last bullet (mof2xmi-rtf)

Click here for this issue's archive.
Source: Adaptive (Mr. Pete Rivett, pete.rivett(at)adaptive.com)
Nature: Uncategorized Issue
Severity:
Summary:

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.

Resolution: Delete last bullet of section 4.10.1.
Revised Text: Delete last bullet of section 4.10.1.
Actions taken:
April 29, 2006: received issue
April 25, 2011: closed issue

Issue 9671: Section 4.10.2.1 (mof2xmi-rtf)

Click here for this issue's archive.
Source: Adaptive (Mr. Pete Rivett, pete.rivett(at)adaptive.com)
Nature: Uncategorized Issue
Severity:
Summary:

4.10.2.1 should also mention the use of XML attributes representign class-typed properties in the metamodel

Resolution: Rephrase section 4.10.2.1 to cover also class-typed properties
Revised Text: Change the content of section 4.10.2.1 from The idref attribute may be used to specify the XML ID of an XML element within the current XML document. Every construct that can be referred to has a local XML ID, a string that is locally unique within a single XML file. To: Every construct that can be referred to has a local XML ID, a string that is locally unique within a single XML file. Attributes representing Class-typed properties in the meatamodel, or XML idref attributes can refer to other XML elements within the same XML file by specifying the target element�s XML ID.
Actions taken:
April 29, 2006: received issue
April 25, 2011: closed issue

Issue 9672: Section 4.10.2.2 (mof2xmi-rtf)

Click here for this issue's archive.
Source: Adaptive (Mr. Pete Rivett, pete.rivett(at)adaptive.com)
Nature: Uncategorized Issue
Severity:
Summary:

 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.

Resolution: Agreed
Revised Text: Delete the first sentence of 4.10.2.2 �Supporting links across documents is optional.�
Actions taken:
April 29, 2006: received issue
April 25, 2011: closed issue

Discussion:

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.

Issue 9673: Co.xml" is not a valid URI! I (mof2xmi-rtf)

Click here for this issue's archive.
Source: Adaptive (Mr. Pete Rivett, pete.rivett(at)adaptive.com)
Nature: Uncategorized Issue
Severity:
Summary:

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

Resolution: Correct URI syntax in examples
Revised Text: In section 4.10.2.2 correct the URI syntax in the examples: In part �1. Using the XMI href attribute to locate an XMI id�, change the example after �As an example:� to: <mgr xmi:id="mgr_1" href="file:Co.xml#emp_2"/> In part �2. Using an XLink simple link and XPointer bare name to locate an XMI id�, change the example after �As an example:� to: <mgr xmi:id="mgr_1" xlink:href="file:Co.xml#emp_2" xlink:type="simple"/> In part �3. Using an XLink simple link and full XPointer to locate an XMI uuid or label�, change the example after �As an example:� to: <mgr xmi:id="mgr_1" xlink:href="file:Co.xml#xpointer((//*[@xmi:uuid='emp_2'])[1])" xlink:type="simple"/>
Actions taken:
April 29, 2006: received issue
April 25, 2011: closed issue

Discussion:

Issue 9674: MOF2 does not have clustering (mof2xmi-rtf)

Click here for this issue's archive.
Source: Adaptive (Mr. Pete Rivett, pete.rivett(at)adaptive.com)
Nature: Uncategorized Issue
Severity:
Summary:

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.

Resolution: Improve the text
Revised Text: In 4.11 replace the following text: 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. By: Typically, the Tags could be in a separate Package and a �super� package could import (via PackageImport) this Tags package and the model package to drive the Schema generation.
Actions taken:
April 29, 2006: received issue
April 25, 2011: closed issue

Issue 9675: Section 4.11, table 4.1 (mof2xmi-rtf)

Click here for this issue's archive.
Source: Adaptive (Mr. Pete Rivett, pete.rivett(at)adaptive.com)
Nature: Uncategorized Issue
Severity:
Summary:

 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.

Resolution: Replace text as described below.
Revised Text: Replace text in the description of attribute in table 4.1, which current reads: If true, serializes the MOF construct as an XML attribute. with: If false, do not serialize the MOF construct as an XML attribute unless element is also false. Also replace text in the description of element in table 4.1, which current reads: If true, serializes the MOF construct as an XML element. with: If false, do not serialize the MOF construct as an XML element unless attribute is also false.
Actions taken:
April 29, 2006: received issue
April 25, 2011: closed issue

Issue 9676: 4.11, table 4.1: 'complex' is repeated in the list of values for contentTyp (mof2xmi-rtf)

Click here for this issue's archive.
Source: Adaptive (Mr. Pete Rivett, pete.rivett(at)adaptive.com)
Nature: Uncategorized Issue
Severity:
Summary:

4.11, table 4.1: 'complex' is repeated in the list of values for contentType

Resolution: Delete text as described below.
Revised Text: Replace text in the description of contentType in table 4.1, which current reads: Defines the schema content type. Other valid values are: complex, any, mixed, complex, and simple. with: Defines the schema content type. Other valid values are: any, mixed, complex, and simple.
Actions taken:
April 29, 2006: received issue
April 25, 2011: closed issue

Issue 9677: tag names should be in bold or full name used (mof2xmi-rtf)

Click here for this issue's archive.
Source: Adaptive (Mr. Pete Rivett, pete.rivett(at)adaptive.com)
Nature: Uncategorized Issue
Severity:
Summary:

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

Resolution: Use long tag names, except in tables 4.1 and 4.2.
Revised Text: Throughout the document, locate all occurrences of all tags listed in table 4.1 and prepend the prefix �org.omg.xmi.� to the tag name, if not already present. Do not change tables 4.1 and 4.2.
Actions taken:
April 29, 2006: received issue
April 25, 2011: closed issue

Issue 9678: Section 4.11.2 (mof2xmi-rtf)

Click here for this issue's archive.
Source: Adaptive (Mr. Pete Rivett, pete.rivett(at)adaptive.com)
Nature: Uncategorized Issue
Severity:
Summary:

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"

Resolution: Replace text as described below
Revised Text: Replace text in the 5th bullet in section 4.11.2 which current reads: If useSchemaExtensions is true, the MOF model must not have multiple inheritance. with: If the MOF model has multiple inheritance, then useSchemaExtensions must be false.
Actions taken:
April 29, 2006: received issue
April 25, 2011: closed issue

Issue 9679: table 4.1 the href attribute (mof2xmi-rtf)

Click here for this issue's archive.
Source: Adaptive (Mr. Pete Rivett, pete.rivett(at)adaptive.com)
Nature: Uncategorized Issue
Severity:
Summary:

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.

Resolution: As proposed, extend the href attribute description and add the constraint
Revised Text: In section 4.11.1, Table 4.1, extend the description of the �href� tag so that the whole description reads: If true, use the href attribute rather than the idref attribute for links within a document. This also prohibits the use of XML attributes for class-typed properties. In section 4.11.2 Add a constraint to the bulleted list, which reads: If href is true, then attribute must be false and element must be true.
Actions taken:
April 29, 2006: received issue
April 25, 2011: closed issue

Issue 9680: last bullet of 4.11.2 (mof2xmi-rtf)

Click here for this issue's archive.
Source: Adaptive (Mr. Pete Rivett, pete.rivett(at)adaptive.com)
Nature: Uncategorized Issue
Severity:
Summary:

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."

Resolution: Change as suggested
Revised Text: In section 4.11.2 change the last bullet from: If the isProperty tag is true, the idName tag is ignored. The tagged property must have type Datatype. Only one isProperty tag may be specified for a class. To: If the idProperty tag is true, the idName tag is ignored. The tagged property must be DataType-typed. Only one idProperty tag may be specified for a class Note, this resolution will be overridden by resolution to 9644
Actions taken:
April 29, 2006: received issue
April 25, 2011: closed issue

Issue 9681: 4.11.3 is largely redundant with, and should be merged with, 4.11.5 (mof2xmi-rtf)

Click here for this issue's archive.
Source: Adaptive (Mr. Pete Rivett, pete.rivett(at)adaptive.com)
Nature: Uncategorized Issue
Severity:
Summary:

4.11.3 is largely redundant with, and should be merged with, 4.11.5

Resolution: Merge 4.11.3 (partially) into 4.11.5; correct table 4.2 in 4.11.5.
Revised Text: Move the second paragraph of section 4.11.3 (�The xmiName�..�) as a new paragraph at the end of text of section 4.11.5, right before table 4.2. In table 4.2 remove the �X� in column �Package Scope� and �Class Scope� for the following tag rows: �serialize�, �contentType� and �remoteOnly�. Then, remove the remaining section 4.11.3 from the document
Actions taken:
April 29, 2006: received issue
April 25, 2011: closed issue

Issue 9682: 4.11.6, 4.11.7 (mof2xmi-rtf)

Click here for this issue's archive.
Source: Adaptive (Mr. Pete Rivett, pete.rivett(at)adaptive.com)
Nature: Uncategorized Issue
Severity:
Summary:

4.11.6, 4.11.7 has: schemaLocation="xmi20.xsd"   which is wrong for XMI 2.1.

Resolution: Replace text as described below
Revised Text: Replace text in the namespace section or 4.11.6 and 4.11.7 which current reads: xmlns:xmi="http://schema.omg.org/spec/XMI/2.1" with: xmlns:xmi="http://schema.omg.org/spec/XMI/2.3"
Actions taken:
April 29, 2006: received issue
April 25, 2011: closed issue

Issue 9683: 4.11.7 has: xmlns:xmi="https://www.omg.org/XMI" which is wrong (mof2xmi-rtf)

Click here for this issue's archive.
Source: Adaptive (Mr. Pete Rivett, pete.rivett(at)adaptive.com)
Nature: Uncategorized Issue
Severity:
Summary:

4.11.7 has: xmlns:xmi="https://www.omg.org/XMI" which is wrong

Resolution: This has been fixed in the current version of the specification. Resolve with no change. Disposition: Closed � No Change
Revised Text:
Actions taken:
April 29, 2006: received issue
May 27, 2011: closed issue

Issue 9684: 4.11.7 uses a type "GM_Curve� which is not defined or described (mof2xmi-rtf)

Click here for this issue's archive.
Source: Adaptive (Mr. Pete Rivett, pete.rivett(at)adaptive.com)
Nature: Uncategorized Issue
Severity:
Summary:

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

Resolution: The purpose of section 4.11.7 is to provide an example of a customized xsd. It is true that GM_Curve is not defined but the objective is achieved because the corresponding xsd:element in the example has a type of "xsd:string
Revised Text: �Add a note below the example reading: NOTE: The definition of type �GM_Curve� is intentionally not shown to keep the example focused and simple.
Actions taken:
April 29, 2006: received issue
April 25, 2011: closed issue

Issue 9685: remove xsd:annotation elements (mof2xmi-rtf)

Click here for this issue's archive.
Source: Adaptive (Mr. Pete Rivett, pete.rivett(at)adaptive.com)
Nature: Uncategorized Issue
Severity:
Summary:

4.11.7 contains several xsd:annotation elements which are neither required nor described as an option by the spec. They should be removed

Resolution: Delete text as described below.
Revised Text: Delete the following text from the example in section 4.11.7: <xsd:annotation> <xsd:documentation>PACKAGE: Cambridge</xsd:documentation> </xsd:annotation> <xsd:annotation> <xsd:documentation>CLASS: Road</xsd:documentation> </xsd:annotation> <xsd:annotation> <xsd:documentation>CLASS: CityFeature</xsd:documentation> </xsd:annotation> <xsd:annotation> <xsd:documentation>CLASS: River</xsd:documentation> </xsd:annotation> <xsd:annotation> <xsd:documentation>CLASS: CityModel</xsd:documentation> </xsd:annotation> <xsd:annotation> <xsd:documentation>CLASS: Mountain</xsd:documentation> </xsd:annotation>
Actions taken:
April 29, 2006: received issue
April 25, 2011: closed issue

Issue 9686: attribute Mountain::elevation (mof2xmi-rtf)

Click here for this issue's archive.
Source: Adaptive (Mr. Pete Rivett, pete.rivett(at)adaptive.com)
Nature: Uncategorized Issue
Severity:
Summary:

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.

Resolution: Replace text as described below
Revised Text: Inside the complexType definition for "Mountain" in the default example replace the xsd:element name definition for "elevation" which currently reads: <xsd:element name="elevation" type="xsd:string" nillable="true"/> with: <xsd:element name="elevation" type="xsd:int" nillable="true"/> Also replace the xsd:attribute name definition for "elevation" which currently reads: <xsd:attribute name="elevation" type="xsd:string" use="optional"/> with: <xsd:attribute name="elevation" type="xsd:int" use="optional"/>
Actions taken:
April 29, 2006: received issue
April 25, 2011: closed issue

Issue 9687: 4.11.7:example should make clear whether this is a CMOF or EMOF metamodel (mof2xmi-rtf)

Click here for this issue's archive.
Source: Adaptive (Mr. Pete Rivett, pete.rivett(at)adaptive.com)
Nature: Uncategorized Issue
Severity:
Summary:

 4.11.7: the example should make clear whether this is a CMOF or EMOF metamodel

Resolution: Add clarification this is EMOF
Revised Text: Replace the following at the end of line 1 of 4.11.7: tailoring an XML schema for a model. By: tailoring an XML schema for a metamodel: in this case an EMOF metamodel.
Actions taken:
April 29, 2006: received issue
April 25, 2011: closed issue

Issue 9688: Section 4.11.7 issue (mof2xmi-rtf)

Click here for this issue's archive.
Source: Adaptive (Mr. Pete Rivett, pete.rivett(at)adaptive.com)
Nature: Uncategorized Issue
Severity:
Summary:

4.11.7: the sentence "This could be addressed by including datatype 'Date' in the model (in Rose as a class with  stereotype <<primitive>> or <<alias>>)" is outdated in its mention of Rose and <<alias>>.

Resolution: It can be useful to be able to indicate that an XSD primitive attribute is used to define the type of an attribute of a class. Perhaps some tools do not offer this capability, and each tool that does offer this capability may have its own way of doing it. We should provide the information about the stereotype so readers of the document have a hint that may give a clue for how to do it with their chosen tool. Replace text as described below
Revised Text: In section 11.7 in the third bullet after the first example replace the second sentence which currently reads: This could be addressed by including datatype �Date� in the model (in Rose as a class with stereotype <<primitive>>) and having XMI tag �schemaType� with value http://www.w3.org/2001/XMLSchema#date. with: This could be addressed by including datatype �Date� in the model and having XMI tag �org.omg.xmi.schemaType� with value http://www.w3.org/2001/XMLSchema#date.
Actions taken:
April 29, 2006: received issue
April 25, 2011: closed issue

Issue 9689: Section 4.11.7 editorial (mof2xmi-rtf)

Click here for this issue's archive.
Source: Adaptive (Mr. Pete Rivett, pete.rivett(at)adaptive.com)
Nature: Uncategorized Issue
Severity:
Summary:

4.11.7: the sentence "the validator would not recognized the additional attributes in Road and River" should use "recognize".

Resolution: It can be useful to be able to indicate that an XSD primitive attribute is used to define the type of an attribute of a class. Perhaps some tools do not offer this capability, and each tool that does offer this capability may have its own way of doing it. We should provide the information about the stereotype so readers of the document have a hint that may give a clue for how to do it with their chosen tool. Replace text as described below.
Revised Text: In the first paragraph after the last bullet after the first example in section 4.11.7 replace the last sentence which currently reads: If we used type=CityFeature, the validator would not recognized the additional attributes in Road and River, and the document would be considered invalid. However, with XMI tag useSchemaExtensions=�true,� the correct type can safely be used. with: If we used type=CityFeature, the validator would not recognize the additional attributes in Road and River, and the document would be considered invalid. However, with XMI tag useSchemaExtensions=�true,� the correct type can safely be used.
Actions taken:
April 29, 2006: received issue
May 27, 2011: closed issue

Issue 9690: 4.12.4 The example addition is not well-formed (mof2xmi-rtf)

Click here for this issue's archive.
Source: Adaptive (Mr. Pete Rivett, pete.rivett(at)adaptive.com)
Nature: Uncategorized Issue
Severity:
Summary:

4.12.4 The example addition is not well-formed - it does not specify that the Class is to be added as an ownedElement of the Package:  <difference xmi:type="xmi:Add" addition="Class_1">  <target href="original.xml#ppp"/>  </difference>

Resolution: This is covered by the resolution for issue 9632. Revised Text: (see resolution for issue 9632) Disposition: Closed � Duplicate of 9632
Revised Text:
Actions taken:
April 29, 2006: received issue
May 27, 2011: closed issue

Issue 9691: 4.12.4 the last XMI fragment (mof2xmi-rtf)

Click here for this issue's archive.
Source: Adaptive (Mr. Pete Rivett, pete.rivett(at)adaptive.com)
Nature: Uncategorized Issue
Severity:
Summary:

4.12.4 the last XMI fragment (after the Replace) is wrong: 4.5.6 states "The Replace class represents the deletion of the target set of objects and the addition of the objects referred to in the replacement attribute." So the delete of the original ppp will also delete the newly added class c2 befor e the addition of the new ppp. So the result will be:  <xmi:XMI version="2.1" xmlns:UML="http://schema.omg.org/spec/UML/1.4"  xmlns:xmi="http://schema.omg.org/spec/XMI/2.1">          <UML:Package xmi:id="ppp" xmi:label="p2"/>  </xmi:XMI>

Resolution: The example is completely replaced by resolution of 9632. Revised Text: Disposition: Closed � Duplicate, Resolved by 9632
Revised Text:
Actions taken:
April 29, 2006: received issue
May 27, 2011: closed issue

Issue 9692: 5.2 rule 1c (mof2xmi-rtf)

Click here for this issue's archive.
Source: Adaptive (Mr. Pete Rivett, pete.rivett(at)adaptive.com)
Nature: Uncategorized Issue
Severity:
Summary:

5.2 rule 1c states "1c. If the schema has a target namespace, the targetNamespace attribute is present." This rule does not make sense as a rule for generating a schema! The rule must say what determines whether a targetNamespace is generated and what its value is (e.g. based on a property of the metamodel or a Tag).  Likewise rule 1d.

Resolution: The issue is correct. It makes sense to use imports for needed declarations from other metamodels which will be in other namespaces through the nature of XMI: hence the syntax should refer to Imports only rather than �ImportsAndIncludes�
Revised Text: In section 5.2 replace the following text describing rule 1c: 1c. If the schema has a target namespace, the targetNamespace attribute is present. By: 1c. The targetNamespace is set to the URI property of the Package representing the metamodel Replace line 2 of the syntax for rule 1: 1d:ImportsAndIncludes? By: 1d:Imports? Replace the syntax for rule 1d: 1d. ImportsAndIncludes::= //Imports and includes// By: 1d. Imports::= //Import statements for referenced metamodels// Replace the text for rule 1: 1. A schema consists of a schema XML element that contains import and include statements, fixed declarations, plus declarations for the contents of the Packages in the metamodel. By: 1. A schema consists of a schema XML element that contains import statements, fixed declarations, plus declarations for the contents of the Packages in the metamodel. Replace the following text describing rule 1d: 1d. If the schema uses declarations from other schemas, the appropriate include or import statements must be present. By: 1d. For each PackageImport in the metamodel there is a XML Schema import element. The namespace attribute will be set to the URI property of the Package defining the metamodel. The schemaLocation attribute is optional for XMI and may be set to the location of the generated XMI-complaint XML Schema for that metamodel.
Actions taken:
April 29, 2006: received issue
April 25, 2011: closed issue

Issue 9693: 5.2 rule 1b and 1h (mof2xmi-rtf)

Click here for this issue's archive.
Source: Adaptive (Mr. Pete Rivett, pete.rivett(at)adaptive.com)
Nature: Uncategorized Issue
Severity:
Summary:

 5.2 rule 1b and 1h: should refer to 'namespace prefix' not 'namespace name' - both in the EBNF and the description. likewise the equivalent rules in section 6.4.1: rules 1b, 1e-h

Resolution: Namespace prefix is much better. All of the sections mentioned should be changed. Replace text as described below
Revised Text: In section 5.2 replace rule 1b which currently reads: 1b. NamespaceDecl ::= "xmlns:" //Namespace name// "=" "�" //Namespace URI// "�" with: 1b. NamespaceDecl ::= "xmlns:" //Namespace prefix// "=" "�" //Namespace URI// "�" In section 5.2 replace rule 1h which currently reads: 1h. Namespace ::= ( //Name of namespace// ":" )? with: 1h. Namespace ::= ( //Name of prefix// ":" )? In section 6.4.1 replace rule 1b which currently reads: 1b:XMINamespace ::= (NsName ":") ? with: 1b:XMINamespace ::= (NsPrefix ":") ? In section 6.4.1 replace rules 1e-h which currently reads: 1e:Namespaces ::= 1f:XMINamespaceDecl ? ( "xmlns:" 1h:NsName "=�" 1i:NsURI "�" )* 1f:XMINamespaceDecl ::= "xmlns=�https://www.omg.org/XMI�" | "xmlns:" NsName "=�https://www.omg.org/XMI�" 1g:Namespace ::= ( 1h:NsName> ":" )? 1h:NsName ::= Name of namespace with: 1e:Namespaces ::= 1f:XMINamespaceDecl ? ( "xmlns:" 1h:NsPrefix "=�" 1i:NsURI "�" )* 1f:XMINamespaceDecl ::= "xmlns=�https://www.omg.org/XMI�" | "xmlns:" NsPrefix "=�https://www.omg.org/XMI�" 1g:Namespace ::= ( 1h:NsPrefix> ":" )? 1h:NsPrefix ::= Name of namespace prefix
Actions taken:
April 29, 2006: received issue
April 25, 2011: closed issue

Issue 9694: 5.2 rule 6 (mof2xmi-rtf)

Click here for this issue's archive.
Source: Adaptive (Mr. Pete Rivett, pete.rivett(at)adaptive.com)
Nature: Uncategorized Issue
Severity:
Summary:

5.2 rule 6 defines PackageElement which seems to have no purpose - such an element will never appear in an XMI file (there is nothing in section 6.4 for it).  So this whole rule 6 and sub-rules 6a to 6h should be deleted.

Resolution: Though a metamodel package defines elements, there is no need for an element for the package itself: there is never the need to exchange an instance of the package �UML� as an XML element for example (as opposed to instances of uml:Model or uml:Package as defined by the UML metamodel). Furthermore there is nothing in section 4.8 covering �Package Representation�. Unlike MOF 1.x, MOF 2 does not support static features : this was one original reason for packageElements at earlier versions of MOF/XMI.
Revised Text: In Section 5.2 Replace rule 2: 2. PackageSchema ::= ( 2:PackageSchema | 3:ClassSchema | 8:EnumSchema)* 6:PackageElementDef By: 2. PackageSchema ::= ( 2:PackageSchema | 3:ClassSchema | 7:AssociationDef | 8:EnumSchema)* Replace: 2. The schema contribution from a Package consists of the declarations for any contained Packages, Classes, Associations without References, enumerations, and an XML element declaration for the Package itself. By: 2. The schema contribution from a Package consists of the declarations for any contained Packages, Classes, Associations and Enumerations. Replace all of ruleset 6 � both the syntax and textual descriptions by the following: 6. This set of rules has been removed but the section number has remained reserved to avoid renumbering the following sections. In Section 6.5.2 Delete the first row in the table: A Package XMIObjectElement. It may contain XMIObjectElements representing other Packages or Classes.
Actions taken:
April 29, 2006: received issue
April 25, 2011: closed issue

Issue 9695: 5.2 rule 7: define 'Unreferenced Association' in MOF2 terms (mof2xmi-rtf)

Click here for this issue's archive.
Source: Adaptive (Mr. Pete Rivett, pete.rivett(at)adaptive.com)
Nature: Uncategorized Issue
Severity:
Summary:

5.2 rule 7: define 'Unreferenced Association' in MOF2 terms

Resolution: In addition the spec is missing a section in section 4.8 for �Association representation� MOF 2 does not have the MOF 1.x distinction between association ends and references. In any case, to support linking elements defined in other documents there is no need to restrict use of the Association syntax.
Revised Text: Add new Section 4.8.9 and renumber existing 4.8.9 Derived Information to 4.8.10 4.8.9 Association Representation Associations are classifiers whose instances are Links. There are cases where it makes sense to serialize Links: for example where the Association owns all of its ends, to link existing elements, or to add a new element to a composition without replacing the existing contents (e.g. to add a Property to a Class where including a new value for package::packagedElement would lose, or require repeating, the complete current list. In 5.2 replace: 7. The declaration of an unreferenced Association consists of the names of its AssociationEnd XML elements. By: 7. The declaration of an Association consists of the names of its AssociationEnd XML elements (whether or not they are owned by the Association). In 6.5.3 replace: As Association, all ends are ownedEnds. By: An Association.
Actions taken:
April 29, 2006: received issue
April 25, 2011: closed issue

Issue 9696: 5.2.2 refers to "XMI 2.0" and has wrong fixed declarations (mof2xmi-rtf)

Click here for this issue's archive.
Source: Adaptive (Mr. Pete Rivett, pete.rivett(at)adaptive.com)
Nature: Uncategorized Issue
Severity:
Summary:

5.2.2 refers to "XMI 2.0" and has wrong fixed declarations that are inconsistent with the XMI model and have wrong xmlns and targetNamespace.

Resolution: Replace text as described below.
Revised Text: Replaces the first 6 lines of the example in section 5.2.2, which currently reads: schema xmlns="http://www.w3.org/2001/XMLSchema" <?xml version="1.0" encoding="UTF-8"?> <xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns="https://www.omg.org/XMI" targetNamespace="https://www.omg.org/XMI"> with: <?xml version="1.0" encoding="UTF-8"?> <xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns="http://schema.omg.org/spec/XMI/2.4" targetNamespace="http://schema.omg.org/spec/XMI/2.4">
Actions taken:
April 29, 2006: received issue
April 25, 2011: closed issue

Issue 9697: Section 7: the examples and rules use Attributes extensively not Properties (mof2xmi-rtf)

Click here for this issue's archive.
Source: Adaptive (Mr. Pete Rivett, pete.rivett(at)adaptive.com)
Nature: Uncategorized Issue
Severity:
Summary:

Section 7: the examples and rules use Attributes extensively not Properties

Resolution: Change �Attribute� to �Property� Revised Text: Changes for section 7 merged into changes defined by resolution to Issue 9653. Disposition: Closed � Duplicate / Related to 9653
Revised Text:
Actions taken:
April 29, 2006: received issue
May 27, 2011: closed issue

Issue 9698: Section 8 (mof2xmi-rtf)

Click here for this issue's archive.
Source: Adaptive (Mr. Pete Rivett, pete.rivett(at)adaptive.com)
Nature: Uncategorized Issue
Severity:
Summary:

Section 8: would be more usefully titled "The XML Schema Metamodel". An electronic version of this metamode is needed. It should reference a specific dated version of the XSD standard. The metamodel should specify the XMI tags required for serializatrion as XMI.

Resolution: The XML Schema metamodel will be moved into the IMM specification when it is adopted. Revised Text: - none - Disposition: Deferred
Revised Text:
Actions taken:
April 29, 2006: received issue
October 20, 2014: deferred

Discussion:

A future RTF shall evaluate the use of the XML Schema metamodel under  development in the in-progress IMM Submission in the way suggested by the issue  author.  Disposition: Deferred

Issue 9699: Appendix A and references (mof2xmi-rtf)

Click here for this issue's archive.
Source: Adaptive (Mr. Pete Rivett, pete.rivett(at)adaptive.com)
Nature: Uncategorized Issue
Severity:
Summary:

Appendix A refers to XML Schema as a 'proposed' recommendation, UML 2.0 as 'an in progress standard' and MOF 2 likewise. Should not need to reference XMI 2.0. Should separate normative references.

Resolution: Superseded by the resolution for issue 9649
Revised Text: (see resolution for issue 9649) In addition: Delete Appendix A Disposition: Resolved � Partial Duplicate to 9649
Actions taken:
April 29, 2006: received issue
April 25, 2011: closed issue

Issue 10112: 4.4 XMI Schema and Document Structure (mof2xmi-rtf)

Click here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:

Change 'Example: <? XML version="1.0" ?>' into 'Example: <?xml version="1.0"?>'. Conforming XML parsers will complain about the bogus '<? XML' with an error message like "missing PI target" or "invalid PI target" and stop processing. See http://www.w3.org/TR/2006/REC-xml11-20060816/#NT-XMLDecl and http://www.w3.org/TR/2006/REC-xml-20060816/#NT-XMLDecl Production: [23] XMLDecl ('xml' must be lowercase and there must not be any character, not even a whitespace character, between '<?' and 'xml') Change 'Example: <? XML version="1.0" ENCODING="UCS-2" ?>' into 'Example: <?xml version="1.0" encoding="ucs-2"?>'. Conforming XML parsers will complain about the bogus 'ENCODING' with an error message like "'?>' expected" and stop processing. See http://www.w3.org/TR/2006/REC-xml11-20060816/#NT-EncodingDecl and http://www.w3.org/TR/2006/REC-xml-20060816/#NT-EncodingDecl Production: [80] EncodingDecl The OMG spec should be clarified to prevent implementers from running into compatibility problems by violating a referenced spec (in this case XML). In case the uppercase notion was chosen for emphasis, look for alternatives like italics, oblique or bold. Additionally I suggest setting these code examples in a fixed width font.

Resolution: Replace text as described below
Revised Text: Replace the first two bullets in section 4.4 which current reads: � An XML version processing instruction. Example: <? XML version=�1.0� ?> � An optional encoding declaration that specifies the character set, which follows the ISO-10646 (also called extended Unicode) standard. Example: <? XML version=�1.0� ENCODING=�UCS-2� ?> with: � An XML version processing instruction. Example: <?xml version="1.0"?> � An optional encoding declaration that specifies the character set, which follows the ISO-10646 (also called extended Unicode) standard. Example: <?xml version="1.0" encoding="ucs-2"?>
Actions taken:
August 18, 2006: received issue
April 25, 2011: closed issue

Issue 10426: Section: 4.11.5 (mof2xmi-rtf)

Click here for this issue's archive.
Nature: Revision
Severity: Minor
Summary:

The tagged values "ordered", "processContents" and "valueSeperator" are missing in table 4.2

Resolution: Insert the missing tags in table 4.2
Revised Text: In section 4.11.5, table 4.2, insert individual rows from the following table into table 4.2 at the appropriate position, for example rows with �MOF Construct Affected� = �Property� shall be inserted into the section of table 4.2, where existing rows have the value �MOF Construct Affected� = �Property�. XMI Tag MOF Construct Affected Package Scope Class Scope Construct Scope ordered Class, Property X X X processContents Class, Property, Package X X X valueSeperator Property X X X
Actions taken:
November 1, 2006: received issue
April 25, 2011: closed issue

Issue 10640: Section: 4.13.3 (mof2xmi-rtf)

Click here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:

In steps 2 and 4 of the example in Section 4.13.3, the text refers to a tool assigning extenderIDs. However, in the subsequent XMI in steps 3 and 5, the values show up as uuids. Is this a mistake, or am I misinterpreting how extenderIDs are used?

Resolution: Correct section 4.13.3
Revised Text: In section 4.13.3: For Step 2, replace: The class is imported into Tool2. Tool2 assigns extenderID �JKLMNOPQRST.� A second class is added with name �c2� and extenderID �X012345678.� By: The class is imported into Tool2. Tool2 assigns extenderID �JKLMNOPQRST.� A second class is added with name �c2� and uuid �X012345678.� For Step 4, replace: The model is imported into Tool1. Tool1 assigns extenderID �ijklmnop� to �c2� and a new class �c3� is created with extenderID �qrstuvwxyz.� By: The model is imported into Tool1. Tool1 assigns extenderID �ijklmnop� to �c2� and a new class �c3� is created with uuid �qrstuvwxyz.�
Actions taken:
February 2, 2007: received issue
April 25, 2011: closed issue

Issue 10658: 4.6.3 Version attribute (mof2xmi-rtf)

Click here for this issue's archive.
Source: David Frankel Consulting (Mr. David Frankel, david(at)dfrankelconsulting.com)
Nature: Uncategorized Issue
Severity:
Summary:

Please can one of our OMG members report this back to the OMG. Comparing these two pages from the XMI v2.1 specification it is apparent that the attribute �version� is �2.0� in on part of the specification and �2.1� in another

Resolution: Handled by resolution to issue 9650 (deleting the version attribute) Revised Text: (See resolution to 9650) Disposition: Closed � Duplicate to 9650
Revised Text:
Actions taken:
February 12, 2007: received issue
May 27, 2011: closed issue

Issue 10659: timestamp (mof2xmi-rtf)

Click here for this issue's archive.
Source: David Frankel Consulting (Mr. David Frankel, david(at)dfrankelconsulting.com)
Nature: Uncategorized Issue
Severity:
Summary:

The XMI specification index contains an entry for a timestamp that is widely implemented by vendors but the definition is missing from the specification. What is the definition?

Resolution: See resolution for Issue 9296. Revised Text: (See resolution for Issue 9296.) Disposition: Closed � Duplicate to 9296
Revised Text:
Actions taken:
February 12, 2007: received issue
May 27, 2011: closed issue

Issue 10772: include an explicit attributeFormDefault setting for the XML Schema (mof2xmi-rtf)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

The OMG XMI v2.1 specification does not include an explicit attributeFormDefault setting for the XML Schema. According to the XML Schema definition this means the attribute form defaults to "unqualified".   http://www.w3.org/TR/2004/REC-xmlschema-1-20041028/structures.html#element-schema    However MagicDraw XMI files have qualified attributes. The MagicDraw XMI files are therefore invalid against the XMI Schema. IMHO this may be a bug.     For example this: <xmi:Extension xmi:Extender="MagicDraw UML 12.0"   xmi:ExtenderID="MagicDraw UML 12.0">    Should be this: <xmi:Extension Extender="MagicDraw UML 12.0"   ExtenderID="MagicDraw UML 12.0">

Resolution:
Revised Text:
Actions taken:
February 15, 2007: received issue
February 20, 2015: closed issue

Discussion:

withdrawn ..implementation issue

Issue 10773: element /xmi:XMI/xmi:Documentation/@xmi:Exporter (mof2xmi-rtf)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

There is another bug in the XMI:         The element /xmi:XMI/xmi:Documentation/@xmi:Exporter should be in lower case according to the OMG XMI v2.1 specification. The element should be renamed "exporter".    This can be verified at https://www.omg.org/docs/formal/05-09-01.pdf on indicated page 11 (page 23 of the PDF).    The same bug is present for /xmi:XMI/xmi:Documentation/@xmi:ExporterVersion, which also needs turning into lower case.         This bug seems prevalent throughout the MagicDraw XMI.

Resolution:
Revised Text:
Actions taken:
February 15, 2007: received issue
February 20, 2015: closed issue

Discussion:

withdrawn ..implementation issue

Issue 10774: MagicDraw's XMI namespace URI (mof2xmi-rtf)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

It looks like there is a small bug in MagicDraw�s implementation of XMI.         MagicDraw's XMI namespace URI is http://schema.omg.org/spec/XMI/2.1     In the standard the OMG has https://www.omg.org/XMI    The URIs are different and incompatible. My MagicDraw version is 12 Enterprise. The version of the OMG XMI specification is:   https://www.omg.org/docs/formal/05-09-01.pdf. This is OMG XMI v2.1.    The suspected bug is registered with MagicDraw

Resolution:
Revised Text:
Actions taken:
February 15, 2007: received issue
February 20, 2015: closed issue

Discussion:

withdrawn ..implementation issue

Issue 11000: Missing XSD files (mof2xmi-rtf)

Click here for this issue's archive.
Source: International Business Machines (Mr. Petko Chobantonov, chobantonov(at)gmail.com)
Nature:
Severity:
Summary:

No separate XSD file is distributed with the specification. Further this XSD should be available on the OMG servers. The specification contains XSD declarations for all XMI classes, but they are embedded in the text and it is not possible for XSD validation tools directly to use it

Resolution: The XMI.xsd file was produced at version 2.1.1 and available on the OMG server. It will be updated as a normal part of producing the XMI 2.4 artifacts Revised Text: - none - Disposition: Closed � No Change
Revised Text:
Actions taken:
May 11, 2007: received issue
May 27, 2011: closed issue

Issue 11001: Fix on xmi:id attribute (mof2xmi-rtf)

Click here for this issue's archive.
Source: International Business Machines (Mr. Petko Chobantonov, chobantonov(at)gmail.com)
Nature: Uncategorized Issue
Severity:
Summary:

The XSD specification states that global attributes cannot be defined as optional. For more information:    http://www.w3.org/TR/xmlschema-0/#Globals    " In other words, global declarations cannot contain the attributes minOccurs, maxOccurs, or use."

Resolution: Though the issue is correct with regard to global attributes in XSDs, XMI defines only one global attribute which is xmi:id and this does not use any of the prohibited minOccurs, maxOccurs or use in the published XMI.xsd file: however production rule 1g does have use=optional.
Revised Text: Replace the following line from rule 1g in section 5: 1g. XMIFixedAttribs ::= ( "<xsd:attribute ref=�xmi:id�" "use=�optional�>" | By: 1g. XMIFixedAttribs ::= ( "<xsd:attribute ref=�xmi:id�>" | In section 5.2 replace the following line: <xsd:attribute name="id" type="xsd:ID" use="optional"/> By: <xsd:attribute name="id" type="xsd:ID "/>
Actions taken:
May 11, 2007: received issue
April 25, 2011: closed issue

Issue 11002: define a new XSD Type (mof2xmi-rtf)

Click here for this issue's archive.
Source: International Business Machines (Mr. Petko Chobantonov, chobantonov(at)gmail.com)
Nature: Uncategorized Issue
Severity:
Summary:

It will be useful to define a new XSD Type that can be used for reference properties instead of xmi:Any. The suggested definition is:      <xsd:complexType name="LinkAttribs" >        <xsd:attributeGroup ref="xmi:LinkAttribs"/>      </xsd:complexType>

Resolution: The text in 4.8.5 describing use of xmi:Any belongs in 4.8.6 for Composites � since only composites have nested elements. The suggestion for a new complex type is unnecessary since the Attribute Group linkAttribs already serves that purpose for non-composites. Production rule 4e needs to have xmi:Any removed. And the presence of min and maxOccurs needs to reflect the specification in the description of the tags in Table 4.1� if not specified they should be set to 0 and unbounded (the default for each is 1).
Revised Text: 4.8.5: Replace the following text: <xsd:element name="r" type="xmi:Any"/> By: <xsd:element name="r" minOccurs="0" maxOccurs=�unbounded�> <xsd:attributeGroup ref="LinkAttribs"/> </xsd:element> Delete the following sentence: A user can override this declaration using the useSchemaExtension tag or the contentType tag. 5.2.1 Replace the rule 4e: 4e. ClassReferences ::= ( "<xsd:element name=�" //Name of Reference// "�" ( 4m:MinOccursAttrib )? ( 4n:MaxOccursAttrib )? (("type=�" 4a:ClassTypeName "�/>") | ("type='xmi:Any'/>")) )* By: 4e. ClassReferences ::= ( "<xsd:element name=�" //Name of Reference// "�" ( 4m:MinOccursAttrib )? ( 4n:MaxOccursAttrib )? �xsd:attributeGroup ref=�linkAttribs��)* In the text for rule 4e, replace: If enforceMinimumMultiplicity is true, the minOccurs attribute is included. If enforceMaximumMultiplicity is true, the maxOccurs attribute is included. By: If enforceMinimumMultiplicity is true, the minOccurs attribute is set to the lowerValue for the Property in the metamodel (unless it is 1 in which case minOccurs is omitted), otherwise it is set to �0� regardless. If enforceMaximumMultiplicity is true, the maxOccurs attribute the minOccurs attribute is set to the upperValue for the Property in the metamodel (unless it is 1 in which case maxOccurs is omitted), otherwise it is set to �unbounded� regardless. In the text for rule 4f, replace: If enforceMinimumMultiplicity is true, the minOccurs attribute is included. If enforceMaximumMultiplicity is true, the maxOccurs attribute is included. By: If enforceMinimumMultiplicity is true, the minOccurs attribute is set to the lowerValue for the Property in the metamodel (unless it is 1 in which case minOccurs is omitted), otherwise it is set to �0� regardless. If enforceMaximumMultiplicity is true, the maxOccurs attribute the minOccurs attribute is set to the upperValue for the Property in the metamodel (unless it is 1 in which case maxOccurs is omitted), otherwise it is set to �unbounded� regardless.
Actions taken:
May 11, 2007: received issue
April 25, 2011: closed issue

Issue 11006: section 4.6.2 XMI Issue: Attribute "href" type (mof2xmi-rtf)

Click here for this issue's archive.
Source: International Business Machines (Mr. Petko Chobantonov, chobantonov(at)gmail.com)
Nature: Uncategorized Issue
Severity:
Summary:

The section 4.6.2 "Linking attributes" defines the attribute "href" with type "xsd:string". Having in mind that semantics of "href" it will be a better choice to use "xsd:anyURI"

Resolution: Change as suggested
Revised Text: In section �4.6.2 Linking Attributes� and in section �5.2.2 Fixed Schema Declarations�, in the definition of <xsd:attributeGroup name="LinkAttribs"> Replace the following line of text: <xsd:attribute name="href" type="xsd:string" use="optional"/> with: <xsd:attribute name="href" type="xsd:anyURI" use="optional"/> Apply the same correction also to the XMI.xsd file.
Actions taken:
May 15, 2007: received issue
April 25, 2011: closed issue

Issue 11511: Spec doesn't provide unified way to specify/represent link references (mof2xmi-rtf)

Click here for this issue's archive. Click here for this issue's attachments.
Source: MEGA International (Mr. Antoine Lonjon, alonjon(at)mega.com)
Nature: Enhancement
Severity: Critical
Summary:

The specification doesn't provide a unified way to specify and represent link references. It is currently possible to use ieth IDREF or href. Furthermore, no standard URI representation is made mandatory. The lack of mandatory reference scheme prevents to ensure interoperability when xmi models are organized in multiple xml files

Resolution: The MOF Facility and Object Lifecycle spec does provide a standard scheme though this is not mandatory. It is referenced from the resolution for 9645. Revised Text: - none - Disposition: Closed � No Change
Revised Text:
Actions taken:
September 26, 2007: received issue
May 27, 2011: closed issue

Discussion:

specification doesn't provide unified way to specify/represent link references

Issue 11512: Section: 4.8.5 (mof2xmi-rtf)

The reference representation of property should not provide the choice between attribute and element. This prevent from using a standard referencing scheme such as XLINK as XLINK cannot be managed as a single attribute. The lack of formal unification of reference representation of properties prevents interoperability between XMI specifications that uses multiple xml documents.

Resolution: This will break too many existing implementations. Close no change. Disposition: Closed � No Change
Revised Text:
Actions taken:
September 26, 2007: received issue
May 27, 2011: closed issue

Issue 11513: Section: 4.8.8 (mof2xmi-rtf)

Click here for this issue's archive.
Source: MEGA International (Mr. Antoine Lonjon, alonjon(at)mega.com)
Nature: Enhancement
Severity: Critical
Summary:

The representation of multiple inheritance prevents from using XSD extension mechanism. As a results, it is impossible to serialize properties which have an abstract type, the sub-type of which having multiple super-type. This is a major issue as it prevents from building a proper, sharable XSD stack.

Resolution: XML does not support multiple inheritance and there is nothing we can do about it. Close no change. Disposition: Closed � No Change
Revised Text:
Actions taken:
September 26, 2007: received issue
May 27, 2011: closed issue

Issue 12859: Use of xmi:type (mof2xmi-rtf)

Click here for this issue's archive.
Source: Adaptive (Mr. Pete Rivett, pete.rivett(at)adaptive.com)
Nature: Uncategorized Issue
Severity:
Summary:

Section 4.6.4. states:    �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.�    And Rule 2g in section 6.4.2 states:    �If the class of the object cannot be determined unambiguously from the model, you must specify the class name using the �type� attribute.�         In general it is never possible to determine a class unambiguously from the model � since any class may be extended with subclasses in model extensions � and many other aspects of XMI are designed to allow for this. The document itself is inconsistent as to whether the xmi:type property is optional: in 4.5.3 it is declared as optional, in 4.6.4 it is not.         Furthermore, the fact that xmi:type is optional makes it impossible in many cases to determine the type of elements, especially if using an XML-based tool without access to the metamodel.         Proposed resolution:    -----------------------    Replace the above quoted sentences with the following:    4.6.4    �The type attribute is used to specify the type of object being serialized.�    6.4.2 2g    �You must specify the class name using the �type� attribute.�         In the example below Figure 6.6 replace:    <Department id=�13�>            <member name=�Glozic�/>            <member name=�Andrews�/>    </Department>    With:    <Department id=�13�>            <member name=�Glozic� xmi:type=�Employee�/>            <member name=�Andrews� xmi:type=�Employee�/>    </Department>

Resolution: Replace text as described below
Revised Text: Remove the �use� attribute in the second to last line of the second example of section 4.6.4 which current reads: <xsd:attribute name="type" type="xsd:QName" use="optional" form="qualified"/> with: <xsd:attribute name="type" type="xsd:QName" form="qualified"/> Add attribute xmi:type in the example below figure 6.6 which current reads: <Department id=�13�> <member name=�Glozic�/> <member name=�Andrews�/> </Department> With: <Department id=�13�> <member name=�Glozic� xmi:type=�Employee�/> <member name=�Andrews� xmi:type=�Employee�/> </Department>
Actions taken:
September 24, 2008: received issue
April 25, 2011: closed issue

Issue 14628: XMI does not allow the differentiation between "set to default" and "unset" states for properties (mof2xmi-rtf)

Click here for this issue's archive.
Source: NASA (Dr. Maged Elaasar, Maged.E.Elaasar(at)jpl.nasa.gov)
Nature: Uncategorized Issue
Severity:
Summary:

Tthe XMI spec clause 6.5.2 says:     "Properties whose values are the default values are not serialized. "      This contradicts the MOF spec, which differentiates between the "set to default" and "unset" states of Properties.     A possible resolution is to change the statement to rather say:     "Property values are serialized when their values are expliclity set (i.e. calling isSet() returns true) and not serialized otherwise."

Resolution: After much discussion the proposal is to clarify the MOF spec such that there will be no distinction between the default value having been implicitly set (on creation) or explicitly set. In other words, there is no need to track and persist the explicit �set� action. And default values are not serialized in either case. On a related point, XMI allows the serialization of a property with a nil value to indicate �that it is empty e.g. <property1 xsi:nil=�true�/>. Also an empty element may be used. Both of these require that an XML element be used for the Property. However this should be made clearer and the rule for this in 2b is incorrect in using xmiName not �xsi� and not allowing empty elements. We should also clarify when the xsi declaration is needed.
Revised Text: In 4.11.2 replace the following: If includeNils is true, and the value of an attribute is nil, the value must be represented by an XML element regardless of the value of the attribute tag. Note that MOF references cannot be set to nil. By: If org.omg.xmi.includeNils is true (the default), and the value of a property is empty, the value must be represented by an XML element regardless of the value of the org.omg.xmi.attribute tag. In Table 4.1, change the default for includeNils to true In 6.4.2 rule 2b, replace the following in 2nd line: | ( "<" xmiName "nil='true'/>" ) By: | ( "<xsi:nil='true'/>" ) Add the following to the end of the description of rule 1e. The namespace declarations must include the following if tag org.omg.xmi.includeNils is true for at least one Property in the metamodel, or org.omg.xmi.useSchemaExtensions is true: xmlns:xsi=�http://www.w3.org/2001/XMLSchema-instance�
Actions taken:
November 11, 2009: received issue
April 25, 2011: closed issue

Issue 15306: Deprecate/remove Chapter 7 (mof2xmi-rtf)

Click here for this issue's archive.
Source: Adaptive (Mr. Pete Rivett, pete.rivett(at)adaptive.com)
Nature: Uncategorized Issue
Severity:
Summary:

Chapter 7 (Production of MOF from XML) is insubstantial and has not been implemented. It has nothing to do with the purpose of XMI � as indicated by the examples which are in terms of application models not metamodels. Its presence diminishes the spec as a whole.

Resolution: Remove Chapter 7.
Revised Text: Delete the whole Chapter 7 from the document. Delete section 2.3.2 Reverse Engineering Compliance
Actions taken:
June 25, 2010: received issue
April 25, 2011: closed issue

Issue 15307: Unclear order of property production (mof2xmi-rtf)

Click here for this issue's archive.
Source: Adaptive (Mr. Pete Rivett, pete.rivett(at)adaptive.com)
Nature: Uncategorized Issue
Severity:
Summary:

When org.xmi.isOrdered is true, it�s not clear what the exact order of properties must be for an element: the spec just refers to the �order of elements in the MOF metamodel� � however both the superclasses and the packagedElement properties are unordered do there is no order that can be used.

Resolution: The precise order is important for cases such as the textual comparison of model files
Revised Text: In table 4.1 replace the following description of ordered: If true, serialize object content in the order it is defined in a MOF model. By: If true, serialize object content in the order it is defined in a MOF model. Where properties have isOrdered=false then the order used is as follows: 5.2.1 Add the following to the end of the text rule 2: The order of definitions within the package is by element type (which includes their subtypes) as follows: Package, Class, Datatype, and alphabetically byname within each element type. 6.4.2 Add the following to the end of the text rule 2: The order of the elements for properties must follow any prescribed XML Schema ordering as defined in Section 5 � even if no XML Schema has actually been generated. Furthermore if the ordered tag is true, the values of multi-valued properties must follow the order in the model (if isOrdered is true for the property) otherwise alphabetic order of the string rendition of that property value.
Actions taken:
June 25, 2010: received issue
April 25, 2011: closed issue

Issue 15308: Unclear XSD production for external metamodels (mof2xmi-rtf)

Click here for this issue's archive.
Source: Adaptive (Mr. Pete Rivett, pete.rivett(at)adaptive.com)
Nature: Uncategorized Issue
Severity:
Summary:

The XMI production rules do not cover the case where a metamodel references elements in other metamodels (e.g. through a Generalization or the type of a Property/Association). Though the Document production rules provide for the use of hrefs, this is not covered in the XSD production e.g. I would expect an xsd:import element (note that MOF does not require packageImports for this case).

Resolution: The use of Imports is covered in the resolution of 9692. Revised Text: (see resolution for issue 9692) Disposition: Closed � Duplicate to / merged with 9692
Revised Text:
Actions taken:
June 25, 2010: received issue
May 27, 2011: closed issue

Issue 15309: Missing rules for production of document by Extent or Object Containment (mof2xmi-rtf)

Click here for this issue's archive.
Source: Adaptive (Mr. Pete Rivett, pete.rivett(at)adaptive.com)
Nature: Uncategorized Issue
Severity:
Summary:

XMI 1.x contained rules for which elements to include in an export (sections 5.3.2 and 5.3.3 of formal/02-01-01). This aspect is entirely missing from XMI 2.x.

Resolution: XMI 1.x contained rules for which elements to include in an export (sections 5.3.2 and 5.3.3 of formal/02-01-01). This aspect is entirely missing from XMI 2.x. Revised Text: This aspect is covered in the description of the export operation in the MOF Facility and Object Lifecycle specification. Disposition: Closed � No Change
Revised Text:
Actions taken:
June 25, 2010: received issue
May 27, 2011: closed issue

Issue 15381: Allow for �tight� schemas (mof2xmi-rtf)

Click here for this issue's archive.
Source: Adaptive (Mr. Pete Rivett, pete.rivett(at)adaptive.com)
Nature: Uncategorized Issue
Severity:
Summary:

If a metamodel has multiple inheritance, XMI has no means to produce an XML Schema to restrict the target of a reference: it is always xsd:any.    Though in theory a metamodel can be extended, it is rarely the case.    Therefore there should be an option to produce an XSD that validates only instances of an unextended metamodel. In fact this should be the default.    There should be a new Boolean XMI tag org.omg.xmi.allowMetamodelExtension which defaults to �false�         This will affect section 4.8.5 and rules 4e and 4f of 5.2.1. And examples. If org.omg.xmi.allowMetamodelExtension is false (the default) then the type of the element will be a union of the metaclass typing the property and any subclass in the metamodel. Abstract classes will not be included.

Resolution: If a metamodel has multiple inheritance, XMI has no means to produce an XML Schema to restrict the target of a reference: it is always xsd:any. Though in theory a metamodel can be extended, it is rarely the case. Therefore there should be an option to produce an XSD that validates only instances of an unextended metamodel. In fact this should be the default. There should be a new Boolean XMI tag org.omg.xmi.allowMetamodelExtension which defaults to �false� This will affect section 4.8.5 and rules 4e and 4f of 5.2.1. And examples. If org.omg.xmi.allowMetamodelExtension is false (the default) then the type of the element will be a union of the metaclass typing the property and any subclass in the metamodel. Abstract classes will not be included.
Revised Text: Add the following to the end of Table 4.1: allowMetamodelExtension boolean false Whether the XML Schema generated should allow for the original metamodel to be extended � allowing subclasses outside the metamodel to be substituted Add the following to the end of Table 4.2: allowMetamodelExtension Property X X X In the example in 4.11.7, replace the following line: <xsd:element name="cityMember" type="xmi:Any"/> By: <xsd:element name="cityMember" type="CityFeature" minOccurs=�0� maxOccurs=�unbounded�/> Delete the following text: � The schema declaration for cityMember has type xmi:Any instead of type CityFeature: <xsd:element name="cityMember" type="xmi:Any"/> It would be useful to be able to constrain the attribute to the correct type - in this case CityFeature instead of Any. In the default case, where XMI tag useSchemaExtensions=�false,� using xmi:Any instead of CityFeature allows the subclasses of CityFeature (Road or River) to be serialized and validated by the schema. If we used type=CityFeature, the validator would not recognized the additional attributes in Road and River, and the document would be considered invalid. However, with XMI tag useSchemaExtensions=�true,� the correct type can safely be used. 4.8.6: Replace the following text in 4.8.6: The form of the XML element is identical to that for association roles. By the following text from 4.8.5: The XML element declaration for a composite property named �r� for a class �c� of type �ClassType� is: <xsd:element name="r" type="ClassType" minOccurs=�0� maxOccurs=�unbounded�/> This element is declared in the content of the complexType for the class that owns the property. If the allowMetamodelExtension tag is set to true then the names of the type is replaced by �xmi:Any�: this declaration enables any object to be serialized, enhancing the extensibility of models. If useSchemaExtension is false (the default) the names of all non-abstract subtypes must also be included (in alphabetic order of immediate children with depth first expansion): if ClassType has subclasses CTS1 and CTS2, and CTS1 has subclass CTS1S1 then the declaration needs to make use of an anonymous complex type: <xsd:element name="r" minOccurs=�0� maxOccurs=�unbounded�> <xsd:complexType> <xsd:choice> <ref=�ClassType�/> <ref=�CTS1�/> <ref=�CTS1S1�/> <ref=�CTS2�/> </xsd:choice> </xsd:complexType> </xsd:element> In 5.2.1 replace the rule for 4f: 4f. ClassCompositions ::= ( "<xsd:element name=�" //Name of Reference// "�" ( 4m:MinOccursAttrib )? ( 4n:MaxOccursAttrib )? (("type=�" 4a:ClassTypeName "�/>") | ("type='xmi:Any'/>")) )* By: 4f. ClassCompositions ::= ( "<xsd:element name=�" //Name of Reference// "�" ( 4m:MinOccursAttrib )? ( 4n:MaxOccursAttrib )? (("type=�" 4a:ClassTypeName "�/>") | ("type='xmi:Any'/>") | (� ><xsd:complexType><xsd:choice>� (�<ref=�� 4a: ClassTypeName "�/>")* �></xsd:choice></xsd:complexType></xsd:element>� ) )* In 5.2.1 in the text for rule 4f, replace: The type is the class name for the Reference type if useSchemaExtensions is �true� or if the contentType is �complex;� otherwise, the type allows any object to be serialized. For references (following 4.8.5 and/or 4.8.6), when useSchemaExtensions is true, the name of the property type is used from rule 4, and when useSchemaExtensions is false, xmi:Any is used. By: The type is the class name for the Reference type if useSchemaExtensions is �true�. If allowMetamodelExtensions is true, the type allows any object to be serialized and xmi:Any is used. Otherwise the list of candidate types is included: this is the name of the Property type (if not abstract) and the name of any non-abstract subclass. The list is in alphabetical order of immediate subclasses with depth first expansion.
Actions taken:
July 25, 2010: received issue
April 25, 2011: closed issue

Issue 15382: Change default of tag org.omg.xmi.contentType (mof2xmi-rtf)

Click here for this issue's archive.
Source: Adaptive (Mr. Pete Rivett, pete.rivett(at)adaptive.com)
Nature: Uncategorized Issue
Severity:
Summary:

This defaults to empty which means that in generated XML schemas there is no ComplexType generated! Which is inconsistent with practice and usefulness, and indeed the examples in the spec document.    The default should be changed to �complex�. This affects Table 4.1 (note that this row duplicates �complex� as a possible value) and  rule 4 of 5.2.1.

Resolution: agreed
Revised Text: In table 4.1, change the default value for tag org.omg.xmi.contentType to �complex�. In section 5.2, change the description for rule 4 to the following text: These rules describe the declaration of a Class in the metamodel as an XML complex type with a content model and XML attributes. If either of the tags enforceMaximumMultiplicity or enforceMinimumMultiplicity is true, the contents of the class are put in a sequence; otherwise, they are put in a choice. If the contentType tag is complex (the default), the class content declarations appear as defined by rule 4b; however, if the contentType value is empty, they do not appear, and if the contentType value is any, the "xsd:any" element declaration appears instead of the class content. If the contentType value is mixed, then the mixed attribute is included. If .useSchemaExtensions is true, the complex type for the class is derived by extension from the complex type for its superclass.
Actions taken:
July 25, 2010: received issue
April 25, 2011: closed issue

Issue 15409: Production rule wrongly includes type on link elements (mof2xmi-rtf)

Click here for this issue's archive.
Source: Adaptive (Mr. Pete Rivett, pete.rivett(at)adaptive.com)
Nature: Uncategorized Issue
Severity:
Summary:

Production rule 2c in section 6.4 is as follows:    2c:XMIReferenceElement::= "<" xmiName (2g:TypeAttrib)? 2l:LinkAttribs "/>"    However this does not make sense: the TypeAttrib is redundant with the xmi:type on the object referenced (making it fragile to change) and the spec says nothing about what happens if they are inconsistent or one may be the superclass of the other. In fact the text describing rule 2c says nothing about the use of 2g or the TypeAttrib:    �2c. Use this production rule to serialize a reference to an object using an XML element. If you use identity     attributes, the values of the identity attributes must match the values of the identity attributes for the object     that is referenced.�    Finally, none of the examples of use of href or idref in the document use the TypeAttrib e.g. example in 4.10.3 or 4.10.2.2.         Proposed resolution: remove the use of 2g from rule 2c

Resolution: Further to the issue, the XSD generated for References (rule 4e) (corrected by resolution to 11002) does not allow for xmi:type to be specified Note that if people want to �cache� the type for whatever reason, that it can be done, as for any other property such as �name�, as per the following bullet of 4.10.1: �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.�
Revised Text: Replace Production rule 2c in section 6.4 as follows: 2c:XMIReferenceElement::= "<" xmiName 2l:LinkAttribs "/>"
Actions taken:
August 6, 2010: received issue
April 25, 2011: closed issue

Issue 15410: Specification makes frequent use of �attribute� and �reference� from MOF 1.4 (mof2xmi-rtf)

Click here for this issue's archive.
Source: Adaptive (Mr. Pete Rivett, pete.rivett(at)adaptive.com)
Nature: Uncategorized Issue
Severity:
Summary:

MOF 2.x removed the distinction yet in many places the terms are still used.    In many cases it does not make much difference but in production rule 4b in section 5.2 it states that �class attributes� should precede �class references�.    If the distinction is preserved the only sensible interpretation would be to define �class reference� as �those Properties of a Class which are association ends � i.e. have association not empty.

Resolution: Duplicate issue. Revised Text: None Disposition: Duplicate of 9653
Revised Text:
Actions taken:
August 6, 2010: received issue
May 27, 2011: closed issue

Discussion:

Issue 15453: The syntax in 6.2.1 allows URI in attributes, which is not mentioned or documented or used elsewhere (mof2xmi-rtf)

Click here for this issue's archive.
Source: Adaptive (Mr. Pete Rivett, pete.rivett(at)adaptive.com)
Nature: Uncategorized Issue
Severity:
Summary:

The syntax in 6.2.1 allows URI in attributes, which is not mentioned or documented or used elsewhere:    2j:XMIReferenceAttribute ::= //xmiName// "=�"                                   ( //refId// | 2n:URIref )+ "�"         This option should be removed.

Resolution: Remove the option as per the issue
Revised Text: In 6.2.1 replace rule 2j by the following: 2j:XMIReferenceAttribute ::= //xmiName// "=�" ( //refId// )+ "�" Replace the following sentence in the description of rule 2j: The value of the XML attribute contains the XMI ID or URI of each referenced object, separated by a space. By: The value of the XML attribute contains the XMI ID of each referenced object, separated by a space. Actions taken: September 8, 2010: received issue
Actions taken:
September 8, 2010: received issue
April 25, 2011: closed issue

Issue 15454: Rule 4i in 5.2 has the following with only 2 options (mof2xmi-rtf)

Click here for this issue's archive.
Source: Adaptive (Mr. Pete Rivett, pete.rivett(at)adaptive.com)
Nature: Uncategorized Issue
Severity:
Summary:

2.       Rule 4i in 5.2 has the following with only 2 options:                               ("type=�xsd:IDREFS� use=�optional�/>"                               | "type=�xsd:IDREF� use=�required�/>"    Why not separate the use from the type and allow all 4 combinations e.g. for an optional single-valued attribute? Or a required multivalued one?

Resolution: Allow all 4 options
Revised Text: In 5.2.1 replace the 2nd and 3rd lines of rule 4i by the following: ("type=�xsd:IDREFS�� | "type=�xsd:IDREF�� ) (�use=�optional�� | �use=�required� " ) �/>� Replace the following sentence in the description of rule 4i: If the multiplicity of the attribute is exactly one, and enforceMinimumMultiplicity is true, the type is IDREF and the attribute is required. By: If the upper bound of the multiplicity of the Property is 1, the type is IDREF otherwise it is IDREFS. If the lower bound is greater than 0 and enforceMinimumMultiplicity is true, then use= required, otherwise use=optional.
Actions taken:
September 8, 2010: received issue
April 25, 2011: closed issue

Issue 15609: Rule 1 references 2:ContentElements which is undefined (mof2xmi-rtf)

Click here for this issue's archive.
Source: Adaptive (Mr. Pete Rivett, pete.rivett(at)adaptive.com)
Nature: Uncategorized Issue
Severity:
Summary:

This is intended to represent arbitrary XML elements which might be unrelated to XMI.

Resolution: Use a comment rather than a numbered clause
Revised Text: In 6.4.1 replace rule 1: 1:Document::= 1a:XMI | 2:ContentElements By: 1:Document::= 1a:XMI | Content Elements And replace the note: 1 The content of an XMI document may be enclosed in an XMI XML element, but it does not need to be. The XML specification requires that there be one root element in an XML document for the document to be well formed. By 1 The content of an XMI document may be enclosed in an XMI XML element, but it does not need to be. The XML specification requires that there be one root element in an XML document for the document to be well formed. The XMI elements(identified via the XMI namespace) may appear anywhere in an arbitrary XML document, intermingled with non-XMI elements � though this can be somewhat restricted through the use of the org.omg.xmi.contentType tag
Actions taken:
September 21, 2010: received issue
April 25, 2011: closed issue

Issue 15610: 1b has been deleted, but it is still referenced from 2g, 2l and 3 (mof2xmi-rtf)

Click here for this issue's archive.
Source: Adaptive (Mr. Pete Rivett, pete.rivett(at)adaptive.com)
Nature: Uncategorized Issue
Severity:
Summary:

1b has been deleted, but it is still referenced from 2g, 2l and 3. I think        those should actually be:        2g:TypeAttribute ::= "xmi:type='" 2k:QName "'"        2l:LinkAttribute ::= "xmi:idref='" //refId// "'" | 2m:Link        3:Extension      ::= "<xmi:extension xmi:type='xmi:Extension'"                             (" extension='" // extender // "'")?                             (" extenderID='" // extenderID // "'")?                             ">"                             || // Extension elements //                             "</xmi:extension>"

Resolution: Take the recommendation from the issue which corrects the resolution of issue 8438.
Revised Text: Replace the rules in section 6.4, as added to by resolution of 8438 with the following text. This also addresses issue 15615. 2g:TypeAttribute ::= "xmi:type='" 2k:QName "'" 2l:LinkAttribute ::= "xmi:idref='" //refId// "'" | 2m:Link 3:Extension ::= "<xmi:extension xmi:type='xmi:Extension'" ("extension='" // extender // "'")? ("extenderID='" // extenderID // "'")? ">" || // Extension elements // "</xmi:extension>"
Actions taken:
September 21, 2010: received issue
April 25, 2011: closed issue

Issue 15611: Use of "xmi:" and //xmiPrefix// is inconsistent. (mof2xmi-rtf)

Click here for this issue's archive.
Source: Adaptive (Mr. Pete Rivett, pete.rivett(at)adaptive.com)
Nature: Uncategorized Issue
Severity:
Summary:

Use of "xmi:" and //xmiPrefix// is inconsistent. 2e and 2f use the latter        even though 1f clearly specifies that xmi is the prefix. "xmi:" should        be used directly in 2e and 2f.

Resolution: resolved
Revised Text: Replace all uses of �//xmiPrefix//� with �xmi:� in section 6.4.
Actions taken:
September 21, 2010: received issue
April 25, 2011: closed issue

Issue 15612: There is a missing colon in 2d. The last line should be (2h:FeatureAttrib)* (mof2xmi-rtf)

Click here for this issue's archive.
Source: Adaptive (Mr. Pete Rivett, pete.rivett(at)adaptive.com)
Nature: Uncategorized Issue
Severity:
Summary:

There is a missing colon in 2d. The last line should be (2h:FeatureAttrib)*

Resolution: As per the issue
Revised Text: In section 6.4.2 replace the last line of rule 2d: (2hFeatureAttrib)* By: (2h:FeatureAttrib)*
Actions taken:
September 21, 2010: received issue
April 25, 2011: closed issue

Issue 15614: When 2n is used with 2j it is supposed to match the last part of schema production (mof2xmi-rtf)

Click here for this issue's archive.
Source: Adaptive (Mr. Pete Rivett, pete.rivett(at)adaptive.com)
Nature: Uncategorized Issue
Severity:
Summary:

When 2n is  used with 2j it is supposed to match the last part of schema production        rule 4i:          | (Qname ? "type='xsd:anyURI' use='optional'/>"))        Is that even valid XML schema? It only allows a single anyURI so 2j        doesn't comply with it. However the description of 4i doesn't mention        it, nor does section 4.8.5 - Reference representation.

Resolution: Issue 15453 identifies the same problem and removes the option to use a URI in 2j. Revised Text: Actions taken: September 21, 2010: received issue Proposed Disposition: Duplicate of 15453
Revised Text:
Actions taken:
September 21, 2010: received issue
May 27, 2011: closed issue

Issue 15615: There's inconsistent use of spacing within quotes (mof2xmi-rtf)

Click here for this issue's archive.
Source: Adaptive (Mr. Pete Rivett, pete.rivett(at)adaptive.com)
Nature: Uncategorized Issue
Severity:
Summary:

There's inconsistent use of spacing within quotes. 3:Extension has spaces within its quoted optional attributes, but none of the other rules follow         this convention.

Resolution: This is taken care of in the resolution to issue 15610 which rewrites the new rule 3..
Revised Text: See 15610
Actions taken:
September 21, 2010: received issue
February 20, 2015: closed issue

Issue 15616: There was an error in the example in Issue 9626 (mof2xmi-rtf)

Click here for this issue's archive.
Source: Adaptive (Mr. Pete Rivett, pete.rivett(at)adaptive.com)
Nature: Uncategorized Issue
Severity:
Summary:

There was an error in the example in Issue 9626:    Operation is a subclass of Element, not ModelElement. ModelElements no longer exist.

Resolution: Make the fix suggested in the issue
Revised Text: Correct the addition made by Issue 9626 which added this to 4.10.3: Operation is a subclass of ModelElement. By changing it to: Operation is a subclass of Element.
Actions taken:
September 21, 2010: received issue
April 25, 2011: closed issue

Issue 15617: The example in Issue 9645 doesn't seem like a particularly good one (mof2xmi-rtf)

Click here for this issue's archive.
Source: Adaptive (Mr. Pete Rivett, pete.rivett(at)adaptive.com)
Nature: Uncategorized Issue
Severity:
Summary:

The example in Issue 9645 doesn't seem like a particularly good one. I would expect the URI for UseCase to be something like:    https://www.omg.org/spec/UML/20100901/uml.xml#UseCase

Resolution: Make the fix suggested in the issue
Revised Text: Correct the addition made by Issue 9645 which added this example to 4.6.1: http://mof.omg.org/MetamodelFacility/UML2Store?uml2/UseCase By changing it to: https://www.omg.org/spec/UML/20100901/uml.xml#UseCase
Actions taken:
October 6, 2010: received issue
April 25, 2011: closed issue

Issue 15618: Resolution text to issue 9650 not consistent (mof2xmi-rtf)

Click here for this issue's archive.
Source: Adaptive (Mr. Pete Rivett, pete.rivett(at)adaptive.com)
Nature: Uncategorized Issue
Severity:
Summary:

The resolution to Issue 9650 is supposed to be removing all traces of xmi:version. However, the final replacement paragraph contains the text "The xmi:version attribute is used to denote the start of XMI information"    which clearly is not consistent with that aim.     The resolution should also mention updates to the XMI document production rules 1c and 1d.

Resolution: Correct the inadvertent retention of the original text mentioning xmi:versio and remove production rules 1c and 1d completely
Revised Text: In 4.5.2 replace the following text (retained from the original by 9650): The xmi:version attribute is used to denote the start of XMI information and identify the XMI version, when the XMI element itself is not present. By: The start of XMI information and identification of the XMI version is indicated by the presence of the XMI namespace declaration, regardless of whether the XMI element itself is present. In 6.4.1 replace the first line of production rule 1a: 1a:XMI ::= "<" 1b:XMINamespace "XMI" 1c:StartAttribs ">" By 1a:XMI ::= "<" 1b:XMINamespace "XMI" 1e:Namespaces ">" Remove production rules 1c and 1d and their notes. Replace the first line of production rule 2d: 2d:XMIAttributes ::= (1c:StartAttribs)? By 2d:XMIAttributes ::= (1c: Namespaces)?
Actions taken:
September 21, 2010: received issue
April 25, 2011: closed issue

Issue 15619: Issue 9673 contained "file:Co.xml" which is an invalid absolute URI (mof2xmi-rtf)

Click here for this issue's archive.
Source: Adaptive (Mr. Pete Rivett, pete.rivett(at)adaptive.com)
Nature: Uncategorized Issue
Severity:
Summary:

Issue 9673 contained "file:Co.xml" which is an invalid absolute URI as it doesn't contain the appropriate initial slashes.    (See section 5.2 of http://www.ietf.org/rfc/rfc2396.txt part (3) for a comment on why relative URIs with a scheme aren't correct.) [PJR] OK

Resolution: Remove the file: from the example.
Revised Text: In the text added by the resolution of 9673, replace the text (3 occurrences): file:Co.xml By: Co.xml
Actions taken:
September 21, 2010: received issue
April 25, 2011: closed issue

Issue 15620: MOF 2.4 references missing (mof2xmi-rtf)

Click here for this issue's archive.
Source: Adaptive (Mr. Pete Rivett, pete.rivett(at)adaptive.com)
Nature: Uncategorized Issue
Severity:
Summary:

The version of MOF serialized is referenced in the Scope, Section1 - but should also be in Normative References. Both need updating to reference MOF 2.4.

Resolution: Add the reference in Normative References, but avoid duplicating it in Scope. Also re-introduce useful text for the Scope, based on wording from the XMI 1.3 formal document
Revised Text: Replace section 1, Scope by the following: XMI is a widely used interchange format for sharing models using XML. XMI defines many of the important aspects involved in describing objects in XML: � The representation of objects in terms of XML elements and attributes is the foundation. � Since objects are typically interconnected, XMI includes standard mechanisms to link objects within the same file or across files. � Object identity allows objects to be referenced from other objects in terms of IDs and UUIDs. � Validation of XMI documents using XML Schemas. XMI describes solutions to the above issues by specifying EBNF production rules to create XML documents and Schemas that share objects consistently. MOF is the foundation technology for describing metamodels, which cover the wide range of domains: this in turn is based on (a constrained subset) of UML. Place the following at the start of the new Section 3 added by issue 9649. � Meta Object Facility (MOF) Core Specification Version 2.4
Actions taken:
September 21, 2010: received issue
April 25, 2011: closed issue

Issue 15621: The replacement text from Issue 15307 for "If true, serialize...is as follows:" doesn't makes sense (mof2xmi-rtf)

Click here for this issue's archive.
Source: Adaptive (Mr. Pete Rivett, pete.rivett(at)adaptive.com)
Nature: Uncategorized Issue
Severity:
Summary:

The replacement text from Issue 15307 for "If true, serialize...is as follows:" doesn't makes sense within the context of table 4.1 as it doesn't proceed to give an ordering. It only makes sense within the revised text section of the resolution itself.    The text from the following addition to 5.2.1 needs to be included or reference made to it

Resolution: Make the fix
Revised Text: Replace the following sentence added to Table 4.1 by Issue 15307: Where properties have isOrdered=false then the order used is as follows: By: Where properties have isOrdered=false then the order used is alphabetic order of the string rendition of that property value.
Actions taken:
September 21, 2010: received issue
April 25, 2011: closed issue

Issue 15860: Section 5.2.1, rule 4b/4c (mof2xmi-rtf)

Click here for this issue's archive.
Source: Adaptive (Mr. Pete Rivett, pete.rivett(at)adaptive.com)
Nature: Uncategorized Issue
Severity:
Summary:

Section 5.2.1, rule 4b/4c uses the phrase �regardless of whether they are marked as derived�. This contradicts the serialize tag and should be removed. Likewise bullet 1 of 6.5.3 implies a choice which does not exist

Resolution: These need to be reconciled with the serialize tag
Revised Text: In section 5.2.1, replace the following text in the description of rules 4b. and 4c.: The complex type for the Class contains XML elements for the contained Attributes, References and Compositions of the Class, plus an extension element, regardless of whether they are marked as derived. The serialize tag can be used to control whether these constructs are serialized. By the following (this includes the text from resolution of 8677 to qualify tag names): The complex type for the Class contains XML elements for the contained DataType-typed and Class-typed properties and Compositions of the Class, plus an extension element. The org.omg.xmi.serialize tag can be used to control whether these constructs are serialized: by default derived constructs are not. In section 6.5.3, replace the following text in bullet 1: This means that either the base or derived form can be serialized, but for a particular serialization only one should be chosen to avoid import confusion. By: This means that either the base or derived form can be serialized, but for a particular metamodel construct only one may be chosen.
Actions taken:
December 2, 2010: received issue
May 27, 2011: closed issue

Issue 15861: Section 5.2.1 rules 4d to 4e (mof2xmi-rtf)

Click here for this issue's archive.
Source: Adaptive (Mr. Pete Rivett, pete.rivett(at)adaptive.com)
Nature: Uncategorized Issue
Severity:
Summary:

Section 5.2.1 rules 4d to 4e: The text still use xmi:Any regardless of the new tag allowMetaModelExtensions - as applied to 4f by issue 15381. The text from that issue should be applied to these rules as well as 4f

Resolution: Update the text as proposed. Also use a better term than �complex attribute� in 4d. And remove redundant text at the end of 4e and 4f.
Revised Text: In section 5.2.1, replace the following text in rule 4d: For complex attributes (possible in CMOF only), when useSchemaExtensions is true, the name of the property type is used from rule 4, and when useSchemaExtensions is false, xmi:Any is used. By: For Properties typed by a structured DataType (possible in CMOF only), when org.omg.xmi.useSchemaExtensions is true, the name of the Property�s type is used from rule 4. When org.omg.xmi.useSchemaExtensions is false and org.omg.xmi.allowMetamodelExtension is true, xmi:Any is used. Otherwise the list of candidate types is included: this is the name of the Property�s type (if not abstract) and the name of any non-abstract subtype. The list is in alphabetical order of immediate subtypes with depth first expansion. In section 5.2.1, replace the following text in rule 4e: The type is the class name for the Reference type if useSchemaExtensions is �true� or if the contentType is �complex;� otherwise, the type allows any object to be serialized. By: The type is the class name for the Class-typed Property type if org.omg.xmi.useSchemaExtensions is �true�. If org.omg.xmi.allowMetamodelExtensions is true, the type allows any object to be serialized and xmi:Any is used. Otherwise the list of candidate types is included: this is the name of the Property type (if not abstract) and the name of any non-abstract subclass. The list is in alphabetical order of immediate subclasses with depth first expansion. At the end of 4e remove the following redundant text: For references (following 4.8.5), when useSchemaExtensions is true, the name of the property type is used from rule 4, and when useSchemaExtensions is false, xmi:Any is used. And at the end of rule 4f remove the following redundant text (as modified by issue 15381): For Class-typed Properties (following 9.8.5 and/or 7.8.6), when org.omg.xmi.useSchemaExtensions is true, the name of the property type is used from rule 4, and when org.omg.xmi.useSchemaExtensions is false, xmi:Any is used.
Actions taken:
December 2, 2010: received issue
May 27, 2011: closed issue

Issue 15862: Section 5.2.1, rule 5: (mof2xmi-rtf)

Click here for this issue's archive.
Source: Adaptive (Mr. Pete Rivett, pete.rivett(at)adaptive.com)
Nature: Uncategorized Issue
Severity:
Summary:

Section 5.2.1, rule 5: Class Elements should only be included if the metaclass is non-abstract

Resolution: Change as recommended
Revised Text: Replace the description for rule 5 in 5.2.1, which currently reads: This rule declares an XML element for a class in a metamodel. By: This rule declares an XML element for a class in a metamodel: such elements should only be included for Classes which have isAbstract = false.
Actions taken:
December 2, 2010: received issue
May 27, 2011: closed issue

Issue 15863: Section 5.2.2: (mof2xmi-rtf)

Click here for this issue's archive.
Source: Adaptive (Mr. Pete Rivett, pete.rivett(at)adaptive.com)
Nature: Uncategorized Issue
Severity:
Summary:

 Section 5.2.2: The elements for documentation must be included within in the �XMI� complexType; Also XMIPackage should be removed as a consequence of Issue 9694. More generally section 5.2.2 duplicates both 4.5.3 (which has the schema presented section by section) and the separate machine readable CMI.xsd file and hence introduces lots of room for error � so should be removed

Resolution: Delete the Schema part of 5.2.2. The documentation elements cannot be included in the complex type for XMI since they would violate the �unique particle attribution rule� since the XMI element also has a xsd:any element. However there is confusion cause by the existence of doth these elements and the elements with upper case: which are only valid if used as top level elements.
Revised Text: Remove the schema definition in section 5.2.2, leaving the existing reference to XMI.xsd. Apply changes made in 5.2.2 )as a result of other issues but not applied to section 4 (illustrating the duplication problem!): (Issue 11001)In 7.6.1 replace: <xsd:attribute name="id" type="xsd:ID" use="optional"/> By: <xsd:attribute name="id" type="xsd:ID"/> (issue 15618) In 7.6.3 remove: <xsd:attribute name="version" type="xsd:string" use="optional" form="qualified"/> In Section 4.5.3 add the following new paragraph after the line <xsd:element name="XMI" type="XMI"/> Note that in the schema that the elements for documentation, difference and extension may not validly be included in the xsd:choice for XMI since that already has xsd:any. However are the elements that must be used within the XMI elements. The Documentation, Difference and Extension elements (starting with uppercase), defined in the following sections, may only be used if they are root elements, not nested underneath XMI, and qualified with the XMI namespace: for example xmi:Documentation.
Actions taken:
December 2, 2010: received issue
April 25, 2011: closed issue

Issue 15864: Section 4.5.3 states that the XMI element is �typically not present� (mof2xmi-rtf)

Click here for this issue's archive.
Source: Adaptive (Mr. Pete Rivett, pete.rivett(at)adaptive.com)
Nature: Uncategorized Issue
Severity:
Summary:

 Section 4.5.3 states that the XMI element is �typically not present� which is not really true and gives the wrong impression. And in fact it is needed for the documentation elements.

Resolution: Adapt the wording.
Revised Text: In section 4.5.3, replace: the XMI element is typically not present when there is only a single top-level object. By: the XMI element may not be present when there is only a single top-level object, but is often useful for consistency and for elements such as Documentation.
Actions taken:
December 2, 2010: received issue
May 27, 2011: closed issue

Issue 15865: Section 4.11.3 needs better clarification (mof2xmi-rtf)

Click here for this issue's archive.
Source: Adaptive (Mr. Pete Rivett, pete.rivett(at)adaptive.com)
Nature: Uncategorized Issue
Severity:
Summary:

Section 4.11.3 needs to better clarify what happens if both element and attribute are both true as per 9675

Resolution: As per suggestion. Also qualify the tag names.
Revised Text: In 4.11.2 replace the following condition for �attribute only�: The feature has an attribute tag set to true. By: The feature has tag org.omg.xmi.attribute set to true and tag org.omg.xmi.element set to false. Replace the following condition for �element only� has an org.omg.xmi.element tag set to true, or By: has tag org.omg.xmi.element set to true and tag org.omg.xmi.attribute set to false, or Replace the following condition for �both attribute and element� The default By: The default, if neither of the above conditions apply
Actions taken:
December 2, 2010: received issue
May 27, 2011: closed issue

Issue 15866: Section 6, rule 2n (mof2xmi-rtf)

Click here for this issue's archive.
Source: Adaptive (Mr. Pete Rivett, pete.rivett(at)adaptive.com)
Nature: Uncategorized Issue
Severity:
Summary:

Section 6, rule 2n: should remove the type/Qname preceding the URI � this is never used for hrefs.

Resolution: As proposed.
Revised Text: In section 6.4.2 replace rule 2n: 2n:URIref ::= (2k:QName)? //URI reference// By: 2n:URIref ::= //URI reference// In the text for 2n remove the following text at the end: The URI reference can be preceded by the type of the object being referenced. For example, a Property�s type is a Classifier, which is abstract. When one of the concrete subclasses of Classifier is actually instantiated, it is not clear which one it is unless the URI is dereferenced. By serializing the QName emof:Class, you can tell it is a Class without needing to load and process the file at the URI.
Actions taken:
December 2, 2010: received issue
May 27, 2011: closed issue

Issue 15867: Section 6.5.2 (mof2xmi-rtf)

Click here for this issue's archive.
Source: Adaptive (Mr. Pete Rivett, pete.rivett(at)adaptive.com)
Nature: Uncategorized Issue
Severity:
Summary:

Section 6.5.2 � should state that �The value of an EnumerationLiteral is its name� (as opposed to �an Enumeration�).

Resolution: Replace as proposed.
Revised Text: In 6.5.2, in the table of rules for EMOF Package, replace the line The value of an Enumeration is its name By: The value of an EnumerationLiteral is its name
Actions taken:
December 2, 2010: received issue
May 27, 2011: closed issue

Issue 15868: Section 6.5.2 � nil=�true� is only used if org.omg.xmi.includeNils = �true� (mof2xmi-rtf)

Click here for this issue's archive.
Source: Adaptive (Mr. Pete Rivett, pete.rivett(at)adaptive.com)
Nature: Uncategorized Issue
Severity:
Summary:

Section 6.5.2 � nil=�true� is only used if org.omg.xmi.includeNils = �true�

Resolution: Clarify as proposed
Revised Text: In 6.5.2, in the table of rules for EMOF Package, replace the line When the value of a Property is null, it is serialized as XMIValueElement with attribute nil=�true�. By: When the value of a Property is null (i.e. empty), it is serialized as XMIValueElement with attribute xsi:nil=�true� if tag org.omg.xmi.includeNils = true. Otherwise it should be serialized as an empty element.
Actions taken:
December 2, 2010: received issue
May 27, 2011: closed issue

Issue 15869: Section 6.5.: (mof2xmi-rtf)

Click here for this issue's archive.
Source: Adaptive (Mr. Pete Rivett, pete.rivett(at)adaptive.com)
Nature: Uncategorized Issue
Severity:
Summary:

Section 6.5.:  The text �The values of the Properties are serialized as a single string separated (by default) by commas.� Is only true if the tag org.omg.xmi.flattenStructuredDatatypes is true� as per issue 8884

Resolution: Explain that the XMIObjectElement syntax can be used, and refer to the earlier description from 8884
Revised Text: In 6.5.3 in the table for CMOF, replace the text: Choice of: 1. XMIValueAttribute 2. Nested XMIValueElement The values of the Properties are serialized as a single string separated (by default) by commas. By: Choice of: 1. XMIObjectElement 2. XMIValueAttribute 3. Nested XMIValueElement By default instances of structured datatypes are serialized as if they were classes, as described in Section 7.8.7. This can be overridden by the tag org.omg.xmi.flattenStructuredDatatypes in which case 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 org.omg.xmi.valueSeparator tag.
Actions taken:
December 2, 2010: received issue
May 27, 2011: closed issue

Issue 16272: attributes which apply to model elements and do not make sense at the XMI element level: (mof2xmi-rtf)

Click here for this issue's archive.
Source: Adaptive (Mr. Pete Rivett, pete.rivett(at)adaptive.com)
Nature: Uncategorized Issue
Severity:
Summary:

  In the XMI.xsd file, the xmi:XMI element has the following attributes which apply to model elements and do not make sense at the XMI element level:    -            <xsd:attribute ref="id"/>    -            <xsd:attributeGroup ref="IdentityAttribs"/>    <xsd:attributeGroup ref="LinkAttribs"/>    <xsd:attribute name="type" type="xsd:QName" use="optional" form="qualified"/>

Resolution: Delete these attributes from the document and the XMI.xsd file.
Revised Text: In clause 7.5.3, delete the following lines from the shown XML code: <xsd:attribute ref="id"/> <xsd:attributeGroup ref="IdentityAttribs"/> <xsd:attributeGroup ref="LinkAttribs"/> <xsd:attribute name="type" type="xsd:QName" use="optional" form="qualified"/> Delete the same lines from XMI.xsd
Actions taken:
May 25, 2011: received issue
February 20, 2015: closed issue

Discussion:

Issue 16273: In the XML Schema production rules the following in rule 4 is missing the option separator |: (mof2xmi-rtf)

Click here for this issue's archive.
Source: Adaptive (Mr. Pete Rivett, pete.rivett(at)adaptive.com)
Nature: Uncategorized Issue
Severity:
Summary:

( "<xsd:complexContent>"                                  "<xsd:extension base=�" 4a:ClassTypeName "�")?    �                                ( "</xsd:extension>"                                  "</xsd:complexContent>" )?    Should be:      ( "<xsd:complexContent>" |                                  "<xsd:extension base=�" 4a:ClassTypeName "�")?    �                                ( "</xsd:extension>" |                                  "</xsd:complexContent>" )?

Resolution: agreed
Revised Text: In clause 8.2.1, rule 4, Insert the EBNF Alternative bars (�|�) before �<xsd:extension base=�� in line 5, and before �</xsd:complexContent>� in line 16 of the rule 4. EBNF
Actions taken:
May 27, 2011: received issue
February 20, 2015: closed issue

Issue 16274: Rule 4f still uses the word �Reference� instead of Class-typed Property (mof2xmi-rtf)

Click here for this issue's archive.
Source: Adaptive (Mr. Pete Rivett, pete.rivett(at)adaptive.com)
Nature: Uncategorized Issue
Severity:
Summary:

4f. ClassCompositions ::= ( "<xsd:element name=�" //Name of Reference// "�"    Should be:    4f. ClassCompositions ::= ( "<xsd:element name=�" //Name of Class-typed Property// "�"

Resolution: agreed
Revised Text: In clause 8.2.1, rule 4f, Replace //Name of Reference// by: //Name of Class-typed Property//
Actions taken:
May 25, 2011: received issue
February 20, 2015: closed issue

Issue 16275: Rule 4f has an extraneous �>� (mof2xmi-rtf)

Click here for this issue's archive.
Source: Adaptive (Mr. Pete Rivett, pete.rivett(at)adaptive.com)
Nature: Uncategorized Issue
Severity:
Summary:

 "></xsd:choice></xsd:complexType></xsd:element>" ) )*    Should be:                                      "</xsd:choice></xsd:complexType></xsd:element>" ) )*

Resolution: agreed
Revised Text: In clause 8.2.1, last line of rule 4f, Replace "></xsd:choice></xsd:complexType></xsd:element>" ) )* by: "</xsd:choice></xsd:complexType></xsd:element>" ) )*
Actions taken:
May 25, 2011: received issue
February 20, 2015: closed issue

Issue 16276: The rule for 6f has become corrupted (mof2xmi-rtf)

Click here for this issue's archive.
Source: Adaptive (Mr. Pete Rivett, pete.rivett(at)adaptive.com)
Nature: Uncategorized Issue
Severity:
Summary:

  ( 6b: DataTypeContents |                                     "<xsd:any minOccurs=�0� maxOccurs=�u                                        processContents=�" // ProcessCont                                   "�/>")?    Should be:                                ( 6b: DataTypeContents |                                     "<xsd:any minOccurs=�0� maxOccurs=�unbounded�                                        processContents=�" // ProcessContents Value //                                    "�/>")?

Resolution: agreed, accept proposal
Revised Text: In clause 8.2.1, in rule 6, Replace ( 6b: DataTypeContents | "<xsd:any minOccurs=�0� maxOccurs=�u processContents=�" // ProcessCont "�/>")? by: ( 6b: DataTypeContents | "<xsd:any minOccurs=�0� maxOccurs=�unbounded� processContents=�" // ProcessContents Value // "�/>")?
Actions taken:
May 25, 2011: received issue
February 20, 2015: closed issue

Issue 16277: The production rule for Associations should use sequence if the tag order is set to true (mof2xmi-rtf)

Click here for this issue's archive.
Source: Adaptive (Mr. Pete Rivett, pete.rivett(at)adaptive.com)
Nature: Uncategorized Issue
Severity:
Summary:

7. AssociationDef    ::= "<xsd:element name=�"� 7a:AssnElmtName �"�>"                             "<xsd:complexType>                             <xsd:choice minOccurs=�0�                                           maxOccurs=�unbounded�>"                             7b:AssnContents                             "</xsd:choice>"                             7d:AssnAtts                              "</xsd:complexType>                             </xsd:element>"    Should be:    7. AssociationDef    ::= "<xsd:element name=�"� 7a:AssnElmtName �"�>"                             "<xsd:complexType>�                             (�<xsd:choice minOccurs=�0�                                           maxOccurs=�unbounded�>" |                              �<xsd:sequence>� )                             7b:AssnContents                             ("</xsd:choice>" | �<xsd:sequence>� )                             7d:AssnAtts                              "</xsd:complexType>                             </xsd:element>"    Replace the text for rule 7:    The declaration of an Association consists of the names of its AssociationEnd XML elements (whether     or not they are owned by the Association).    With:    The declaration of an Association consists of the names of its AssociationEnd XML elements (whether     or not they are owned by the Association). If org.omg.xmi.ordered is true then a sequence is used (with the order of ends being that form the metamodel), otherwise  a choice.

Resolution: agreed
Revised Text: In clause 8.2.1, rule 7, Replace the EBNF of rule 7. AssociationDef (up until the start of rule 7a.) by: 7. AssociationDef ::= "<xsd:element name=�"� 7a:AssnElmtName �"�>" "<xsd:complexType>� (�<xsd:choice minOccurs=�0� maxOccurs=�unbounded�>" | �<xsd:sequence>� ) 7b:AssnContents ("</xsd:choice>" | �</xsd:sequence>� ) 7d:AssnAtts "</xsd:complexType> </xsd:element>" In the table describing rule 7, replace the text: The declaration of an Association consists of the names of its AssociationEnd XML elements (whether or not they are owned by the Association). by: The declaration of an Association consists of the names of its AssociationEnd XML elements (whether or not they are owned by the Association). If org.omg.xmi.ordered is true then a sequence is used (with the order of ends being that form the metamodel), otherwise a choice.
Actions taken:
May 25, 2011: received issue
February 20, 2015: closed issue

Issue 16330: No unambiguous way in XMI 2.4 UML 2.4 to serialize UML 2.4's StructuredActivityNode (mof2xmi-rtf)

Click here for this issue's archive.
Source: No Magic, Inc. (Mr. Nerijus Jankevicius, nerijus(at)nomagic.com)
Nature: Revision
Severity: Critical
Summary:

We just recently had discussion with Ed about an issue with Activity::node and Activity::group. Both are composite non-derived properties and it causes problems with all StructuredActivityNodes, which are ActivityNodes and ActivityGroups at the same time.   MagicDraw or Eclipse implementation of UML does not allow to own the same element in two composites , even if owner element is the same.  Does XMI support that?    So, ExpansionRegion or any other StructuredActivityNode appears in Activity::group only.      fUML spec/engine expects to find them in Activity::node , as all owned nodes should be there.    Any suggestions? Don't you think we should fix that somehow?

Resolution:
Revised Text:
Actions taken:
June 10, 2011: received issue
September 17, 2012: closed issue

Discussion:

The problem is that the combination of the UML, MOF and XMI specs taken together do not provide an adequate specification of how to serialize StructuredActivityNodes, which leads to ambiguity. Currently, the ownership of StructuredActivityNode by Activity is derived, and is a subset of Activity::node and Activity::group. This leads to the question of whether a StructuredActivityNode should be serialized as a node, as a group, or both. This has obvious impacts on model interchange, and also impacts fUML. The solution is to make the ownership of StructuredActivityNode by Activity non-derived, and then fix the MOF semantics and XMI serialization rules to ensure that a StructuredActivityNode is serialized in a structuredNode element, and not in a node or a group element. This resolution fixes the XMI part; there are two counterpart issues corresponding to the UML and XMI parts. The problem with XMI 2.4 is in the table in section 9.4.1 where it says �A Property, type is not a PrimitiveType or Enumeration, isComposite = true� must be serialized with a Nested XMIObjectElement. This does not take account of situations where more than one composite property contains the same value, which is true for the case at hand. The resolution is to note that according to MOF rules, there is only one property in the contained object that has a slot referring to the owner, and that the XMIObjectElement should be serialized for the property opposite that unique owner property. Other composite properties in the same object with the same value must be serialized using a reference element. Revised text: Underneath table 9.4.1, add the following new �additional rule�: ItIn table 9.4.1, in the XMI Representation column corresponding to �A Property, type is not a PrimitiveType or Enumeration, isComposite = true�, replace the existing text �Nested XMIObjectElement� by the following: When the object has only one non-derived property with isComposite = true, that property is serialized as a nested XMIObjectElement. However, it may be the case that an object has more than one non-derived property with isComposite=true, all containing the same value. In such a case, because of MOF constraints, only one of those properties will may have an opposite with a non-empty slot. The property with the non-empty opposite slot is serialized as a nested XMIObjectElement, and the others are notserialized either as XMIReferenceAttributes or nested XMIReferenceElements. Disposition: Resolved

Issue 16331: XMI composite opposite constraint overly restrictive (mof2xmi-rtf)

Click here for this issue's archive.
Source: Oracle (Mr. Dave Hawkins, dave.hawkins(at)oracle.com)
Nature: Clarification
Severity: Minor
Summary:

Section 9.4.1 of the specification contains the following constraint:      For Properties with isComposite=true, the opposite property is not serialized.    While this is fine when objects are nested it doesn't make sense when an object is serialised as a root object. For example, stereotype extensions are mapped to composite associations. Stereotypes instances are serialised as root objects because the composite property is not owned by the extended class. To attach them to their extended object the 'base' property is serialised, but this is the opposite of a property with isComposite=true.

Resolution: The constraint should be made specific to where the composite property is itself the one used for nesting
Revised Text: In Section 9.4.1 replace the following constraint: For Properties with isComposite=true, the opposite Property is not serialized. By: For Properties with isComposite=true where that Property is used for nesting the owned element in this XMI file, the opposite Property is not serialized.
Actions taken:
June 13, 2011: received issue
February 20, 2015: closed issue

Issue 16889: Grammar for XML Schema - XMI 2.4 Beta (mof2xmi-rtf)

Click here for this issue's archive. Click here for this issue's attachments.
Source: Georgia Institute of Technology (Dr. Mark Kindl, mark.kindl(at)gtri.gatech.edu)
Nature: Uncategorized Issue
Severity:
Summary:

As part of our UML work for the National Information Exchange Model (NIEM) we have encountered what appear to be errors in the grammars for XML Schema in several XMI specs.  Please let us know if we have misinterpreted these issues

Resolution:
Revised Text: Replace the text in rule 1, which current reads: 1. Schema ::= 1a:SchemaStart 1d:Imports? 1e:FixedDeclarations 2:PackageSchema+ 1f:SchemaEnd 1a. SchemaStart ::= "<xsd:schema xmlns:xsd=�http://www.w3.org/2001/XMLSchema� xmlns:xmi=�https://www.omg.org/spec/XMI/20100901� 1b:NamespaceDecl* 1c:TargetNamespace? ">" 1b. NamespaceDecl ::= "xmlns:" //Namespace prefix// "=" "�" //Namespace URI// "�" 1c. TargetNamespace ::= "targetNamespace=�" //Namespace URI// "�" 1d. Imports ::= //Import statements for referenced metamodels// 1e. FixedDeclarations ::= "<xsd:import namespace=�https://www.omg.org/spec/XMI/20100901�/>" 1f. SchemaEnd ::= "</xsd:schema>" 1g. XMIFixedAttribs ::= "<xsd:attribute ref=�xmi:id�/>" "<xsd:attributeGroup ref=�xmi:ObjectAttribs�/>" 1h. Namespace ::= ( //Name of prefix// ":" )? with: 1. Schema ::= 1a:SchemaStart 1d:Imports? 1e:FixedDeclarations 2:PackageSchema+ 1f:SchemaEnd 1a. SchemaStart ::= "<xsd:schema" " xmlns:xsd=�http://www.w3.org/2001/XMLSchema�" " //XMI URL// " 1b:NamespaceDecl* 1c:TargetNamespace? ">" 1b. NamespaceDecl ::= " xmlns:" //Namespace prefix// "=" "�" //Namespace URI// "�" 1c. TargetNamespace ::= " targetNamespace=�" //Namespace URI// "�" 1d. Imports ::= //Import statements for referenced metamodels// 1e. FixedDeclarations ::= "<xsd:import" " //XMI URL// />" 1f. SchemaEnd ::= "</xsd:schema>" 1g. XMIFixedAttribs ::= "<xsd:attribute ref=�xmi:id�/>" "<xsd:attributeGroup ref=�xmi:ObjectAttribs�/>" 1h. Namespace ::= ( //Name of prefix// ":" )? Replace the text in rule 4, which current reads: 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> 4a. ClassTypeName ::= 1h:Namespace //Name of Class// 4b. ClassContents ::= 4d:ClassAttributes 4e:ClassReferences 4f:ClassCompositions 4c:Extension 4c. Extension ::= ("<xsd:element ref=�xmi:extension�/>")* 4d. ClassAttributes ::= ("<xsd:element name=�" //Name of DataType-typed Property// "�" ("nillable=�true�")? ( 4m:MinOccursAttrib )? ( 4n:MaxOccursAttrib )? (("type=�" //Name of type// "�/>") | ("type='xmi:Any'/>")) )* 4e. ClassReferences ::= ( "<xsd:element name=�" //Name of Class-typed Property// "�" ( 4m:MinOccursAttrib )? ( 4n:MaxOccursAttrib )? "xsd:attributeGroup ref=�linkAttribs�")* 4f. ClassCompositions ::= ( "<xsd:element name=�" //Name of Reference// "�" ( 4m:MinOccursAttrib )? ( 4n:MaxOccursAttrib )? (("type=�" 4a:ClassTypeName "�/>") | ("type='xmi:Any'/>")/>") | (" ><xsd:complexType><xsd:choice>" ("<ref=�" 4a: ClassTypeName "�/>")* "></xsd:choice></xsd:complexType></xsd:element>" ) )* 4g. ClassAttListItems ::= 1g:XMIFixedAttribs 4h:ClassAttribAtts 4h. ClassAttribAtts ::= ( 4i:ClassAttribRef | 4j:ClassAttribData | 4k:ClassAttribEnum )* 4i. ClassAttribRef ::= "<xsd:attribute name=�" //Name of attribute// "�" ("type=�xsd:IDREFS�" | "type=�xsd:IDREF�" ) ("use=�optional�" | use=�required�" ) "/>" | (QName ? "type=�xsd:anyURI� use=�optional�/>")} 4j. ClassAttribData ::= "<xsd:attribute name=�" //Name of attribute// "�" "type=�xsd:string� " ("use=�optional�" | "use=�required�") ("form=�" // Form value // "�")? "/>" 4k. ClassAttribEnum ::= "<xsd:attribute name=�" //Name of attribute// "�" "type=�" 8a:EnumTypeName "�" ("use=�optional�" | "use=�required�")) "/>" 4l. // rule deleted// 4m. MinOccursAttrib ::= "minOccurs=�" // Minimum // "�" 4n. MaxOccursAttrib ::= "maxOccurs=�" // Maximum // "�" with: 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>" 4a. ClassTypeName ::= 1h:Namespace //Name of Class// 4b. ClassContents ::= 4d:ClassAttributes 4e:ClassReferences 4f:ClassCompositions 4c:Extension 4c. Extension ::= ("<xsd:element ref=�xmi:extension�/>")* 4d. ClassAttributes ::= ("<xsd:element name=�" //Name of DataType-typed Property// "�" (" nillable=�true�")? ( 4m:MinOccursAttrib )? ( 4n:MaxOccursAttrib )? ((" type=�" //Name of type// "�/>") | (" type='xmi:Any'/>")) )* 4e. ClassReferences ::= ( "<xsd:element name=�" //Name of Class-typed Property// "�" ( 4m:MinOccursAttrib )? ( 4n:MaxOccursAttrib )? "/>")* 4f. ClassCompositions ::= ( "<xsd:element name=�" //Name of Reference// "�" ( 4m:MinOccursAttrib )? ( 4n:MaxOccursAttrib )? ( (" type=�" 4a:ClassTypeName "�/>") | (" type='xmi:Any'/>") | (" >" ("<xsd:complexType>" "<xsd:choice>" ("<xsd:element ref=�" 4a: ClassTypeName "�/>")* "</xsd:choice>" "</xsd:complexType>" )* </xsd:element>" ) )) 4g. ClassAttListItems ::= 1g:XMIFixedAttribs 4h:ClassAttribAtts 4h. ClassAttribAtts ::= ( 4i:ClassAttribRef | 4j:ClassAttribData | 4k:ClassAttribEnum )* 4i. ClassAttribRef ::= "<xsd:attribute name=�" //Name of attribute// "�" ( ( (" type=�xsd:IDREFS�" | " type=�xsd:IDREF�" ) (" use=�optional�" | " use=�required�" ) ) | (" type=�xsd:anyURI� use=�optional�") ) "/>" 4j. ClassAttribData ::= "<xsd:attribute name=�" //Name of attribute// "�" " type=�xsd:string� " (" use=�optional�" | " use=�required�") (" form=�" // Form value // "�")? "/>" 4k. ClassAttribEnum ::= "<xsd:attribute name=�" //Name of attribute// "�" " type=�" 8a:EnumTypeName "�" (" use=�optional�" | " use=�required�") "/>" 4l. // rule deleted// 4m. MinOccursAttrib ::= " minOccurs=�" // Minimum // "�" 4n. MaxOccursAttrib ::= " maxOccurs=�" // Maximum // "�" Replace the text in rule 5, which current reads: 5. ClassElementDef ::= "<xsd:element name=�" //Name of class// "�" "type=� 4a:ClassTypeName "�/>" with: 5. ClassElementDef ::= "<xsd:element name=�" //Name of class// "�" " type=� " 4a:ClassTypeName "�/>" Replace the text in rule 6, which current reads: 6. StructuredDataTypeDef::= "<xsd:complexType name=�" //Name of DataType// ("mixed=�true�")? "�>" ( "<xsd:complexContent>" "<xsd:extension base=�" 6a:DataTypeName ("<xsd:choice minOccurs=�0� maxOccurs=�unbounded�>" | "<xsd:sequence>")? ( 6b: DataTypeContents | "<xsd:any minOccurs=�0� maxOccurs=�u processContents=�" // ProcessCont "�/>")? ("</xsd:choice>" | "</xsd:sequence>")? 4g:ClassAttListItems ( "</xsd:extension>" "</xsd:complexContent>" )? "</xsd:complexType> 6a. DataTypeName ::= 1h:Namespace //Name of DataType// 6b. DataTypeContents ::= 4d: ClassAttributes 4c:Extension with: 6. StructuredDataTypeDef::= "<xsd:complexType name=�" //Name of DataType// "� " (" mixed=�true�")? ">" ( "<xsd:complexContent>" "<xsd:extension base=�" 6a:DataTypeName "�>" ("<xsd:choice minOccurs=�0� maxOccurs=�unbounded�>" | "<xsd:sequence>")? ( 6b: DataTypeContents | "<xsd:any minOccurs=�0� maxOccurs=�unbounded� " " processContents=�" // ProcessContents // " "�/>")? ("</xsd:choice>" | "</xsd:sequence>")? 4g:ClassAttListItems "</xsd:extension>" "</xsd:complexContent>" )? "</xsd:complexType>" 6a. DataTypeName ::= 1h:Namespace //Name of DataType// 6b. DataTypeContents ::= 4d: ClassAttributes 4c:Extension Replace the text in rule 7, which current reads: 7. AssociationDef ::= "<xsd:element name=�"� 7a:AssnElmtName �"�>" "<xsd:complexType> <xsd:choice minOccurs=�0� maxOccurs=�unbounded�>" 7b:AssnContents "</xsd:choice>" 7d:AssnAtts "</xsd:complexType> </xsd:element>" 7a. AssnElmtName ::= 1h: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 with: 7. AssociationDef ::= "<xsd:element name=�"� 7a:AssnElmtName �"�>" "<xsd:complexType>� "<xsd:choice minOccurs=�0� " " maxOccurs=�unbounded�>" 7b:AssnContents "</xsd:choice>" 7d:AssnAtts "</xsd:complexType>" "</xsd:element>" 7a. AssnElmtName ::= 1h: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 Replace the text in rule 5, which current reads: 8. EnumSchema ::= "<xsd:simpleType name=�" 8a:EnumType "�>" "<xsd:restriction base=�xsd:string�>" 8c:EnumLiterals "</xsd:restriction>" "</xsd:simpleType>" 8a. EnumTypeName ::= 1h:Namespace 8b:EnumName 8b. EnumName ::= // Name of enumeration // 8c. EnumLiterals ::= ("<xsd:enumeration value=�" 8d:EnumLiteral "�/>")+ 8d. EnumLiteral ::= // Name of enumeration literal // with: 8. EnumSchema ::= "<xsd:simpleType name=�" 8a:EnumTypeName "�>" "<xsd:restriction base=�xsd:string�>" 8c:EnumLiterals "</xsd:restriction>" "</xsd:simpleType>" 8a. EnumTypeName ::= 1h:Namespace 8b:EnumName 8b. EnumName ::= // Name of enumeration // 8c. EnumLiterals ::= ("<xsd:enumeration value=�" 8d:EnumLiteral "�/>")+ 8d. EnumLiteral ::= // Name of enumeration literal //
Actions taken:
December 8, 2011: received issue
February 20, 2015: closed issue

Issue 16890: Grammar for XML Schema - XMI XMI 2.1.1 (mof2xmi-rtf)

As part of our UML work for the National Information Exchange Model (NIEM) we have encountered what appear to be errors in the grammars for XML Schema in several XMI specs.  Please let us know if we have misinterpreted these issues

Resolution:
Revised Text:
Actions taken:
December 8, 2011: received issue
February 20, 2015: closed issue

Discussion:

XMI Version 2.1.1 has been superseded by XMI Version 2.4.1, which will soon be  superseded by XMI Version 2.5. Numerous corrections have been applied during this  evolution, making this issue obsolete. (Note, this is content-wise a duplicate of  16889).  Disposition: Closed � No Change

Issue 17389: An XMIReferenceElement cannot be used for serializing a composite property (mof2xmi-rtf)

Click here for this issue's archive.
Source: Model Driven Solutions (Mr. Ed Seidewitz, ed-s(at)modeldriven.com)
Nature: Uncategorized Issue
Severity:
Summary:

Specification: OMG MOF XMI Mapping Specification, Version 2.4.1 (formal/2011-08-09)         Subclause 9.4.1 EMOF Package requires that �A property, type is not a PrimitiveType or Enumeration, isComposite=true� have an XMI representation of �Nested XMIObjectElement�. Nothing in Subclause 9.4.2 CMOF Package alters this.         The BNF for an XMIObjectElement is given in Subclause 9.5.2 Object Structure by production 2a:XMIObjectElement. This production does allow such an element to include 2d:XMIAttributes, but such attributes do not include hrefs. The production 2m:Link is the one for hrefs, and this is used in 2l:LinkAttribs, which is, in turn, used only by 2c:XMIReferenceElement. It is not included directly in 2a:XMIObjectElement.         So, the conclusion is that something like �<packagedElement href=���/> would not be a valid EMOF/CMOF serialization, since that is an XMIReferenceElement, not and XMIObjectElement, and packagedElement is a composite property. Divide a large model based on its hierarchical composition structure into across multiple XMI files, resulting in tool-specific approaches for such modularization in most major UML tools.         Suggested resolution: In the last line of the table in Subclause 9.4.1, change the XMI representation of �XMIObjectElement� to:         Choice of:     1.       Nested XMIObjectElement     2.       Nested XMIReferenceElement

Resolution: This was in fact already addressed at XMI 2.4.1. However the text could be further clarified to cover the multiple file case and generally tidied (e.g. to remove the typo �clot�).
Revised Text: In 9.4.1 replace: the following text in the last cell: Normally, serialized properties with isComposite = true are serialized as nested XMIObjectElements. Exceptionally it may be the case that a containing object has more than one serialized class-typed property with isComposite = true that contain the same object or include it among their collection of objects. In such an exceptional case, because of MOF constraints, only one of those properties can have an opposite with a non-empty clot. Objects of the property with the non-empty opposite slot are serialized as nested XMIObjectElements, and the other references to the same object are serialized either as XMIReferenceAttributes or nested XMIReferenceElements By: Choice of: 1. Nested XMIObjectElement 2. Nested XMIReferenceElement 2. Nested XMIReferenceAttribute Normally, serialized properties with isComposite = true are serialized as nested XMIObjectElements. In the case where the model is split across more than one file then a nested XMIReferenceElement would be used. Exceptionally, even within one file, it may be the case that a containing object has more than one serialized classtyped property with isComposite = true that contain the same object or include it among their collection of objects. In such an exceptional case, because of MOF constraints, only one of those properties can have an opposite with a non-empty slot. Objects of the property with the non-empty opposite slot are serialized as nested XMIObjectElements, and the other references to the same object are serialized either as XMIReferenceAttributes or nested XMIReferenceElements.
Actions taken:
May 22, 2012: received issue
February 20, 2015: closed issue

Issue 17494: Section B6 (mof2xmi-rtf)

Click here for this issue's archive.
Source: Oracle (Mr. Dave Hawkins, dave.hawkins(at)oracle.com)
Nature: Uncategorized Issue
Severity:
Summary:

I think it would be helpful if uuids were limited to valid  URIs. An href is typed as xsd:anyURI, so if a uuid is a URI  it is straightforward to use in an href. If the uuid is not  a URI the href is more complex, probably requiring the  document URL, which, given an id must also be present, would  make the uuid pointless. (This comment applies for uuids  in general. In JDeveloper we've taken uuids to be URIs.)      Additionally, it is impossible for an importing tool to ensure  arbitrary string uuids generated by different exporting tools  are unique. A standard URI scheme gives some hope that if two  uuids are the same, they are the same object.

Resolution: Requiring that UUIDs be URIs would be a drastic change beyond the powers of an RTF. Also, such a change would break almost any existing tool implementation and is therefore discouraged. Disposition: Closed � No Change
Revised Text:
Actions taken:
July 13, 2012: received issue
October 22, 2013: Transferred to XMI RTF
February 20, 2015: closed issue

Discussion:

Requiring uuids to be URIs would be too large a change for this RTF    Disposition:	Deferred

Issue 17718: The text should be reviewed for clarity and objectivity and then amended (mof2xmi-rtf)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

The technical intent of the document is reasonably clear, and it appears to have been used for several effective implementations.  The presentation of the material in the document is a long way from the ISO/IEC format, which is permitted for the first version of a standard introduced by the JTC1 PAS process, but there are a number of places where small changes would bring it closer to what users of ISO/IEC standards usually expect.  There are also a number of places where the text is unclear or does not make obvious sense.  Large tracts of motivational and background material tend to obscure the normative specifications. The text should be reviewed for clarity and objectivity, and then suitably amended before it is further considered for progression to IS.

Resolution: The proposed change is not sufficiently detailed to be actionable.. Disposition: Close No Change
Revised Text:
Actions taken:
September 25, 2012: received issue
February 20, 2015: closed issue

Issue 17719: Section1: The intended scope of the standard is unclear (mof2xmi-rtf)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

The intended scope of the standard is unclear.  The first sentence is unnecessary commentary.  The second sentence implies that this standard defines only some of the important aspects of defining objects using XML, but ignores others.  The final sentence refers to MOF, but does not relate it in any way to what has gone before.	Change the Scope to:  This International Standard supports the Meta Object Facility (MOF) Core defined in ISO/IEC 19508 by defining mechanisms for the use of XML elements and attributes for representation of objects defined using the MOF.  It defines mechanisms that may be used to link objects within the same file of in different files; supports references between objects in terms of Ids and UUIDS; and supports validation of XMI documents using XML schemas.

Resolution: Replace clause 1, which current reads: XMI is a widely used interchange format for sharing models using XML. XMI defines many of the important aspects involved in describing objects in XML: � The representation of objects in terms of XML elements and attributes is the foundation. � Since objects are typically interconnected, XMI includes standard mechanisms to link objects within the same file or across files. � Object identity allows objects to be referenced from other objects in terms of IDs and UUIDs. � Validation of XMI documents using XML Schemas. XMI describes solutions to the above issues by specifying EBNF production rules to create XML documents and Schemas that share objects consistently. MOF is the foundation technology for describing metamodels, which cover the wide range of domains: this in turn is based on (a constrained subset) of UML. with: This International Standard supports the Meta Object Facility (MOF) Core defined in ISO/IEC 19508. MOF is the foundation technology for describing metamodels. It covers a wide range of domains, and is based on a constrained subset of UML. XMI is a widely used XML interchange format. It defines the following aspects involved in describing objects in XML: � The representation of objects in terms of XML elements and attributes. � The standard mechanisms to link objects within the same file or across files. � The validation of XMI documents using XML Schemas. � Object identity, which allows objects to be referenced from other objects in terms of IDs and UUIDs. XMI describes solutions to the above issues by specifying EBNF production rules to create XML documents and Schemas that share objects consistently.
Revised Text:
Actions taken:
September 25, 2012: received issue
February 20, 2015: closed issue

Discussion:

The complaints listed in the summary are mostly true, but the proposed change goes  too far and eliminates important things in the specification. The proposed resolution  makes the last sentence be the first, and removes a few ambiguous words

Issue 17720: Section 2.1 - delete (mof2xmi-rtf)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

This clause contains what are, essentially, definitions of the terms �XMI Document� and �XMI Schema�, together with a sentence that does not obviously achieve what it claims to do.  The subclause does not describe anything.	Delete this clause 2.1, and include definitions of �XMI Document� and �XMI Schema� in clause 4.

Resolution: Replace the second sentence in clause 2.1, which current reads: �XMI Document� and �XMI Schema� are defined as documents and schemas produced by the XMI production (document and XML schema) rules defined in this specification. with: The terms �XMI Document� and �XMI Schema� are defined in Clause 4. Replace 4, which current reads: There are no formal definitions in this specification that are taken from other documents. with: The following are the only terms defined in this standard. There are no other terms used in this document with meanings that cannot be found in other standards. [XMI Document] A document produced by the XMI production rules defined in this specification. [XMI Schema] A schema produced by the XMI production rules defined in this specification.
Revised Text:
Actions taken:
September 25, 2012: received issue
February 20, 2015: closed issue

Discussion:

Definitions for �XMI Document� and �XMI Schema� are needed in clause 4, and  clause 2.1 will be changed to say that these two terms will be described below.

Issue 17721: Section 2.2.2 (mof2xmi-rtf)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

The first bullet is imprecise, although its intention is reasonably clear.  It attempts to impose requirements that cannot be verified easily, or perhaps at all. Replace the bullet with:  An XMI document shall be �valid� and �well formed�, as defined in the W3C XML Recommendation.  If associated with a specific XML schema, then it shall be consistent with that XML schema.

Resolution:
Revised Text:
Actions taken:
September 25, 2012: received issue
February 20, 2015: closed issue

Discussion:

An XMI document must always remain compliant with its XML schema even if it isn�t  checked.  Disposition: Close No Change

Issue 17722: Section 2.3.1 (mof2xmi-rtf)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

Rather than referring to page numbers within the document, internal cross-references should identify clause numbers and titles. 	Include clause numbers, rather than page numbers in the references to �XMI Model� and �Tailoring Schema Production�.

Resolution: Replace both bullets in clause 2.3.1, which current reads: � The guidelines for using the extension elements suggested in �XMI Model� on page 8 are found there and in �Tailoring Schema Production� on page 26. Tools should place their extended information within elements that are not in the XMI namespace or within elements that have the XMI namespace and a tag name of �Extension.� They should also declare the nature of the extension using the standard XMI elements where applicable, and preserve the extensions of other tools that fall within the XMI namespace. � Processing of XMI differencing elements (�Effects on Document Production� on page 31) is an optional compliance point. with: � The guidelines for using the extension elements suggested in clause 7.5 �XMI Model� are found there and in clause 7.11 �Tailoring Schema Production�. Tools should place their extended information within elements that are not in the XMI namespace or within elements that have the XMI namespace and a tag name of �Extension.� They should also declare the nature of the extension using the standard XMI elements where applicable, and preserve the extensions of other tools that fall within the XMI namespace. � Processing of XMI differencing elements (�Effects on Document Production� in clause 7.11.5) is an optional compliance point.
Revised Text:
Actions taken:
September 25, 2012: received issue
February 20, 2015: closed issue

Issue 17723: Section 3 references (mof2xmi-rtf)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

Where a referenced document has been published, or is in the course of publication, as an International Standard, as is the case for the MOF, then the reference should be to the IS version. Change the reference for the Meta Object Facility to ISO/IEC 19508, which should have been published no later than the IS version of the current document.  Make similar changes for any other referenced documents that have been published in ISO, IEC or ITU versions.

Resolution: Change clause 3 , from: " The following referenced documents are indispensable for the application of this document. For dated references, only the edition cited applies. For undated references, the latest edition of the referenced document (including any amendments) applies. � Meta Object facility (MOF) Core Specification, Version 2.4.1 https://www.omg.org/spec/MOF � Extensible Markup Language (XML) 1.0 (Fifth Edition) W3C Recommendation 26 November 2008 � XML Schema Part 1: Structures Second Edition W3C Recommendation 28 October 2004 � XML Schema Part 2: Datatypes Second Edition W3C Recommendation 28 October 2004 � XML Linking Language (XLink) Version 1.1 W3C Recommendation 06 May 2010 � XPointer Framework W3C Recommendation 25 March 2003 � XPointer element() Scheme W3C Recommendation 25 March 2003 � XPointer xmlns() Scheme W3C Recommendation 25 March 2003 " To the following: ' The following referenced documents are indispensable for the application of this document. For dated references, only the edition cited applies. For undated references, the latest edition of the referenced document (including any amendments) applies. � [MOF] "ISO/IEC 19508:2013 "Information technology - Object Management Group - Meta Object Facility Core" (OMG Specification Meta Object facility (MOF) Core Specification, Version 2.4.2 - https://www.omg.org/spec/MOF/2.4.2) � [UMLInfra] "ISO/IEC 19505-1:2012 , Information technology � Object Management Group - Unified Modeling Language (OMG UML) � Part 1: Infrastructure" (OMG Specification Unified Modeling Language (OMG UML) Version 2.4.1 �Part 2: Infrastructure - https://www.omg.org/spec/UML/2.4.1/Superstructure) � [UMLSuper] "ISO/IEC 19505-2:2012 , Information technology � Object Management Group - Unified Modeling Language (OMG UML) - Part 2: Superstructure" (OMG Specification Unified Modeling Language (OMG UML) Version 2.4.1 �Part 2: Superstructure - https://www.omg.org/spec/UML/2.4.1/Superstructure) � [XML] " Extensible Markup Language (XML) 1.0 (Fifth Edition) W3C Recommendation 26 November 2008 http://www.w3.org/TR/2008/REC-xml- 20081126/ � [XMLSchema1] "XML Schema Part 1: Structures Second Edition" W3C Recommendation 28 October 2004 http://www.w3.org/TR/2004/REC-xmlschema-1- 20041028/ � [XMLSchema2] "XML Schema Part 2: Datatypes Second Edition" W3C Recommendation 28 October 2004 http://www.w3.org/TR/2004/REC-xmlschema-2- 20041028/ � [XLink] " XML Linking Language (XLink) Version 1.1" W3C Recommendation 06 May 2010 http://www.w3.org/TR/2010/REC-xlink11-20100506/ � [XPointerFramework] "XPointer Framework" W3C Recommendation 25 March 2003 http://www.w3.org/TR/2003/REC-xptr-framework-20030325/ � [XPointerElement] "XPointer element() Scheme" W3C Recommendation 25 March 2003 http://www.w3.org/TR/2003/REC-xptr-element-20030325/ � [XPointerXmls] "XPointer xmlns() Scheme" W3C Recommendation 25 March 2003 http://www.w3.org/TR/2003/REC-xptr-xmlns-20030325/ � [NAMESP] "Namespaces in XML 1.0 (Third Edition)" W3C Recommendation 8 December 2009 http://www.w3.org/TR/2009/REC-xml-names-20091208/ � [INFOSET] "XML Information Set (Second Edition)" W3C Recommendation 4 February 2004 http://www.w3.org/TR/2004/REC-xml-infoset-20040204
Revised Text:
Actions taken:
September 25, 2012: received issue
February 20, 2015: closed issue

Discussion:

Agree to change references to OMG specs which have been progressed as ISO/IEC  standards via PAS, to indicate both the ISO/IEC and OMG designations.  The resolution to this Issue includes the additional OMG references added from  resolution to Issue 17734 and 17743

Issue 17724: Section 4 (mof2xmi-rtf)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

Whilst the statement that the document contains no formal definitions taken from other documents may well be true, it is not particularly useful.  It may also be true that no terms are used in this document with meanings that cannot be found in common dictionaries.  If this is the case, then a statement to that effect would be more useful than the existing statement.  Otherwise definitions of terms that are used with special meanings must be included here.  There are a number of abbreviations that are used in the body of the document without explanation.  They should be expanded or otherwise explained here. Include an �Abbreviation� clause, and if appropriate a populated Definitions clause.

Resolution:
Revised Text:
Actions taken:
September 25, 2012: received issue
February 20, 2015: closed issue

Discussion:

This issue is covered by the resolution to issue 17720.  Disposition: Duplicate Issue 17720

Issue 17725: Section 6 - delete clause (mof2xmi-rtf)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

It is not usual in ISO or IEC standards to acknowledge contributors to the document.  It is not obvious that in all cases the terms used uniquely identify a specific organisation.	Delete the clause.

Resolution: Replace clause 6 text, which current reads: The following companies submitted and/or supported parts of this specification: � Adaptive � Ceira Technologies, Inc. � Compuware Corporation � DSTC � Hewlett-Packard � International Business Machines � IONA � MetaMatrix � Softeam � Sun Microsystems � Telelogic, AB � Unisys � University of Kent with: 6.1 Acknowledgements Annex C contains an informative list of companies which contributed to this specification . Add a new Informative Annex Annex C Acknowledgements This annex is informative The following companies submitted and/or supported parts of this specification: 88 Solutions, Adaptive, Ceira Technologies, Inc., Compuware Corporation, DSTC, Hewlett-Packard, International Business Machines, IONA, MetaMatrix, Raytheon, Softeam, Sun Microsystems, Telelogic, AB, Unisys, University of Kent
Revised Text:
Actions taken:
September 25, 2012: received issue
February 20, 2015: closed issue

Discussion:

Companies require their contributions to be acknowledged. However, 88 Solutions  and Raytheon should be added, and the bulletized list should be replaced with the  company names separated by commas.  Have clause 6.1 reference a new informative annex with the list of  acknowledgements

Issue 17726: Section 7.11.6: Move the example to an informative annex and delete the clause from its present position. (mof2xmi-rtf)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

This clause contains an extended example and does not contain any requirements.  It is out of place in the body of a standard.	Move the example to an informative annex and delete the clause from its present position.

Resolution: Add the following as a new first sentence to 7.11.6 "The example in this subclause is informative." Change the caption for Figure 7.3 from: " Figure 7.3 - GIS Cambridge model " To: " Figure 7.3 - GIS Cambridge meta model
Revised Text:
Actions taken:
September 25, 2012: received issue
February 20, 2015: closed issue

Discussion:

Add an indication that this subclause is informative

Issue 17727: Section 7.12 (mof2xmi-rtf)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

This hanging paragraph is but one example of the considerable amount of background and motivational text that occurs throughout the document.  Such material may be appropriate in an introductory textbook, but is out of place in a standard.  All such material should be removed from the body of the standard, leaving only detailed specification expressing requirements on implementers of products and other artefacts conforming to the standard .	Delete all explanatory and motivational material from the body of the standard.  Really useful elements may be moved to one or more informative annexes.

Resolution: Place the hanging paragraphs into a new subclause, with a designation that 17.12 is informative " 17.12.1 Motivation Subclause 17.12 is informative, and is not required for conformance. The goal is to provide a mechanism for specifying the differences between documents so that an entire document does not need to be transmitted each time. This design does not specify an algorithm for computing the differences, just a form for transmitting them. Up to now we have seen how to transmit an incomplete or full model. This way of working may not be adequate for allenvironments. More precisely, we could mention environments where there are many model changes that must be transmitted very quickly to other users. For these environments the full model transmission can be very resource consuming (time, network traffic, ...) making it very difficult or even not viable for finding solutions for cooperative work. The most viable way to solve this problem is to transmit only the model changes that occur. In this way different instances of a model can be maintained and synchronized more easily and economically. Concurrent work of a group of users becomes possible with a simple mechanism to synchronize models. Transmitting less information allows synchronizing models more efficiently.
Revised Text:
Actions taken:
September 25, 2012: received issue
February 20, 2015: closed issue

Discussion:

This clause 17.12 is informative, but is still useful. It should not be  deleted.  The proposal to delete all informative material is not detailed enough to be  actionable.

Issue 17728: Title page i (mof2xmi-rtf)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

Category �Object Management Group� is not adequate for standards. Change to �Information technology -- Object Management Group MOF 2 XMI Version 2.4.1�.

Resolution:
Revised Text:
Actions taken:
September 25, 2012: received issue
February 20, 2015: closed issue

Discussion:

This issue is covered by the resolution to issue 17729.  Disposition Close No Change

Issue 17729: Title page i: f �MOF 2 XMI� in a title means �MOF to XMI�, it is not adequate (mof2xmi-rtf)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

If �MOF 2 XMI� in a title means �MOF to XMI�, it is not adequate.	Change the title if it means �to�.

Resolution: Change the title, which current reads: OMG MOF 2 XMI Mapping Specification with: Object Management Group - XML Metadata Interchange (XMI)
Revised Text:
Actions taken:
September 25, 2012: received issue
February 20, 2015: closed issue

Issue 17730: Foreword Page vii (mof2xmi-rtf)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

Title of ISO/IEC 19505-2:2011 is different. Use �ISO/IEC 19505-2:2012 Information technology -- Object Management Group Unified Modeling Language (OMG UML) -- Part 2: Superstructure�.

Resolution: Change reference in the forward to the following: " ISO/IEC 19505-2:2012 , Information technology � Object Management Group - Unified Modeling Language (OMG UML) � Part 2: Superstructure "
Revised Text:
Actions taken:
September 25, 2012: received issue
February 20, 2015: closed issue

Issue 17731: Foreword Page vii: Title of ISO/IEC DIS 195058 is different. (mof2xmi-rtf)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

Title of ISO/IEC DIS 195058 is different. Use �ISO/IEC DIS 195058 Information technology -- Object Management Group -- Meta Object Facility (MOF) Core Version 2.4.1�.

Resolution: There is no need for the version number in the title. Change reference in the forward to the following: " ISO/IEC 19508:2013 "Information technology - Object Management Group - Meta Object Facility (MOF) Core "
Revised Text:
Actions taken:
September 25, 2012: received issue
February 20, 2015: closed issue

Issue 17732: Section 1 Scope: The statements are not for the Scope (mof2xmi-rtf)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

The statements are not for the Scope. The area or range of this standard should be stated clearly.

Resolution:
Revised Text:
Actions taken:
September 25, 2012: received issue
February 20, 2015: closed issue

Discussion:

This issue is covered by the resolution to issue 17718.  Disposition: Duplicate

Issue 17733: Section 2 Normative Reference: ISO/IEC standards were not specified (mof2xmi-rtf)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

ISO/IEC standards were not specified. MOF(ISO/IEC19502) and XMI(ISO/IEC19502)  MOF4.2 (ISO/IEC29505) should be considered

Resolution:
Revised Text: Add the following new subclause 6.1 to explain why 19508 and 19509 do not supersede the existing ISO/IEC standards19501 and 10502, which are cited in the Bibliography. " 6.1 Relationship to existing standards for MOF and XMI This Internationals Standard is aligned with [MOF2] and [UML2], which are not backwards compatible with the following existing International Standards � [UML1 ] ISO/IEC 19501:2005 , Information Technology - Open Distributed Processing - Unified Modeling Language (UML) Version 1.4.2" � [MOF1] ISO/IEC 19502:2005 , Information technology -- Meta Object Facility (MOF) [XMI1] ISO/IEC 19503:2005, Information technology -- XML Metadata Interchange (XMI) Because existing specifications reference these 2005 standards, and they are not superseded by this International Standard, these 2005 standards remain in force. There are no normative references to these 2005 standards required in this International Standard.
Actions taken:
September 25, 2012: received issue
February 20, 2015: closed issue

Discussion:

The UML 1.x aligned version of MOF and XMI are not normatively referenced in this  specification.  However there is a need to explain that the UML 1.x aligned versions are not  backwards compatible, and thus are not superseded by these new UML 2.x aligned  versions

Issue 17734: Clause �Additional Information� is not needed. (mof2xmi-rtf)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

Clause �Additional Information� is not needed. Delete this clause or move to an informative annex except as copyright.

Resolution: Add formal reference to UML 2.4.1 superStructure and infrastructure specs " � [UMLInfra] "ISO/IEC 19505-1:2012 , Information technology � Object Management Group - Unified Modeling Language (OMG UML) � Part 1: Infrastructure" (OMG Specification Unified Modeling Language (OMG UML) Version 2.4.1 �Part 2: Infrastructure - https://www.omg.org/spec/UML/2.4.1/Superstructure) � [UMLSuper] "ISO/IEC 19505-2:2012 , Information technology � Object Management Group - Unified Modeling Language (OMG UML) � Part 2: OMG Issue No: 17734 Disposition: Resolved XMI 2.5 RTF Report � URGENT BALLOT 2.4.2 Page 77 of 95 Superstructure" (OMG Specification Unified Modeling Language (OMG UML) Version 2.4.1 �Part 2: Superstructure - https://www.omg.org/spec/UML/2.4.1/Superstructure) " Add formal reference to XML namespace spec: " � [NAMESP] "Namespaces in XML 1.0 (Third Edition)" W3C Recommendation 8 December 2009 http://www.w3.org/TR/2009/REC-xml-names-20091208/ " See resolution for Issue 17743 for an additional normative reference to be added.
Revised Text:
Actions taken:
September 25, 2012: received issue
February 20, 2015: closed issue

Discussion:

Issue 17743 explicitly asks to include an additional normative reference to XML  infoset.  UML 2.4.1 superstructure needs to be added as a Normative Reference, because  UML notation is used in a normative manner in this specification.  UML 2.3.1 Infrastructure also is refered to in a normative manner, and should be  added as a normative reference.  XML namespace spec is essential for understanding the use of XMI namespaces, so  it neds to be added as a normative reference.

Issue 17735: Section 7.1, 2nd Paragraph (mof2xmi-rtf)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

That definition is presented in Clause 8 rather than 7. Change Clause 7 to Clause 8.

Resolution:
Revised Text:
Actions taken:
September 25, 2012: received issue
February 20, 2015: closed issue

Discussion:

This issue is covered by the resolution to issue 17725.  Disposition: Duplicate to 17725

Issue 17736: Section 3 Terms and Definitions (mof2xmi-rtf)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

Other documents should be specified.	Titles should be specified as referencing definitions.

Resolution: Replace the last sentence in the second paragraph in clause 7.1, which current reads: That definition is presented in Chapter 7. with: That definition is presented in Clause 8 Replace the last sentence in the secondparagraph of clause 7.1, which current reads: That definition is presented in Clause 7. with: That definition is presented in Clause 8.
Revised Text:
Actions taken:
September 25, 2012: received issue
February 20, 2015: closed issue

Issue 17737: Section 7.1, 3rd Paragraph (mof2xmi-rtf)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

There is a sentence �See Clause 10 for a complete description of how to generate XML schema using these tag value pairs.� However, there is no sentence related tag value pair in Clause 10.  Delete this sentence �See Clause 10 ...�

Resolution: Delete the second to last sentence of para 3 of 7.1, which currently reads: " See Clause 10 for a complete description of how to generate XML schemas using these tag value pairs. "
Revised Text:
Actions taken:
September 25, 2012: received issue
February 20, 2015: closed issue

Discussion:

The offending sentence is not critical, and it is unclear whether it should refer to  Clause 8 instead of Clause 10.  To avoid confusion, it is best to delete the sentence

Issue 17738: Section 7.10.3 (mof2xmi-rtf)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

This sub sub clause describes informative example only. Move to an annex.

Resolution: Insert the following as a 1 sentence paragraph before the first paragraph of clause 7.10.3: This sub clause is informative.
Revised Text:
Actions taken:
September 25, 2012: received issue
February 20, 2015: closed issue

Issue 17739: Section 7.11.6 (mof2xmi-rtf)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

There is no element named Cambridge as described in the default XML schema for this model. Delete an element named Cambridge from a schema or add an element into a diagram.

Resolution: That element named "Cambridge" should be renamed to "GIS" the name of the metamodel. This element is the root element in the schema for the XMI document for a model instance of this meta model. Change title of Figure 17.3 from: GIS Cambridge model To GIS meta model In both occurrences in 17.11.6 change <xsd:element name="Cambridge"> To: <xsd:element name="GIS">
Revised Text:
Actions taken:
September 25, 2012: received issue
February 20, 2015: closed issue

Issue 17740: Section 7.11.6: change type=�CitiMember� to type=�CitiFeature� (mof2xmi-rtf)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

There is an element named CitiMember typed CitiMember. However, there is no complex type named CitiMember in a diagram... Change type=�CitiMember� to type=�CitiFeature� .

Resolution: In the second schema for CitiMember type change: <xsd:element name="cityMember" type="CityMember" minOccurs="0" maxOccurs="unbounded"/> to <xsd:element name="cityMember" type="CityFeature" minOccurs="0" maxOccurs="unbounded"/>
Revised Text:
Actions taken:
September 25, 2012: received issue
February 20, 2015: closed issue

Issue 17741: Section 7.12.4 (mof2xmi-rtf)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

This sub sub clause describes informative example only. Move to an annex.

Resolution: Partially resolved by resolution to Issue 17727 Replace the title of clause 7.12.5, which current reads: 7.12.5 Example with: 7.12.5 Example of Differences Insert the following as a 1 sentence paragraph before the first paragraph of clause 7.12.4: This sub clause is informative.
Revised Text:
Actions taken:
September 25, 2012: received issue
February 20, 2015: closed issue

Issue 17742: Section 10 (mof2xmi-rtf)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

Issue as XML Schema Inforset Model is informative. Delete it or move to an annex.

Resolution: Replace the title of clause 9.2, which current reads: 9.2 Introduction with: 9.2 Overview
Revised Text:
Actions taken:
September 25, 2012: received issue
February 20, 2015: closed issue

Issue 17743: Section 9.2: Change �introduction� to �general.� (mof2xmi-rtf)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

Clause �introduction� explains informative sentences usually. However, this clause explains an overview of XML Document Production. Change �introduction� to �general.�

Resolution: Add the following bullet to the bottom of the list of bullets in clause 3: � [INFOSET] "XML Information Set (Second Edition)" W3C Recommendation 4 February 2004 http://www.w3.org/TR/ 2004/REC-xml-infoset-20040204
Revised Text:
Actions taken:
September 25, 2012: received issue
February 20, 2015: closed issue

Discussion:

Infoset is a normative reference

Issue 17744: Annex A Page 73 (mof2xmi-rtf)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

These references are informative. Put �(informative)� under the title.

Resolution: Replace the title of Annex A, which current reads: Annex A - References with: Annex A - Bibliography Replace the contents of Annex A, which current reads: [XML] XML, a technical recommendation standard of the W3C. http://www.w3.org/TR/REC-xm. [XML Schema] XML Schemas, a proposed recommendation of the W3C. Primer: http://www.w3.org/TR/xmlschema-0/, Structured types: http://www.w3.org/TR/xmlschema-1/ Data types: http://www.w3.org/TR/xmlschema-2/. [NAMESP] Namespaces, a technical recommendation of the W3C. http://www.w3.org/TR/REC-xml-names [XLINK] XLinks, a working draft of the W3C. http://www.w3.org/TR/WD-xlink and http://www.w3.org/TR/NOTE-xlink-principles [XPath] XPointer, technical recommendation of the W3C. http://www.w3.org/TR/xpath [UML] UML 2.0, an in progress standard of the OMG. More specifically, this refers to the UML 2.0 Infrastructure submission. See https://www.omg.org/techprocess/meetings/schedule/UML_2.0_I nfrastructure_RFP.html . [MOF] MOF 2.0, an in progress standard of the OMG. More specifically, thisrefers to the MOF 2.0 Core submission. See https://www.omg.org/techprocess/meetings/schedule/MOF_2.0_ Core_RFP.html. [XMI] XMI 2.0, an adopted standard of the OMG. https://www.omg.org with: [XLINK] "XML Linking Language (XLink) Version 1.0" W3C Recommendation 27 June 2001 http://www.w3.org/TR/2001/REC-xlink-20010627/ [XPath] "XML Path Language (XPath) Version 1.0" W3C Recommendation 16 November 1999 http://www.w3.org/TR/1999/REC-xpath-19991116 [UML1] � "ISO/IEC 19501:2005 , Information Technology - Open Distributed Processing - Unified Modeling Language (UML) Version 1.4.2" [MOF1] "ISO/IEC 19502:2005 , Information technology - Meta Object Facility (MOF)" [XMI1] "ISO/IEC 19503:2005 , Information technology � XML Metadate Interchange (XMI)"
Revised Text:
Actions taken:
September 25, 2012: received issue
February 20, 2015: closed issue

Discussion:

Change the title of Annex A to "Bibliography", and update the annex to reference  current standards which are used in an informative manner in the body of the  specification.  Do not repeat references which are Normative references in the body of the  document..

Issue 17745: Annex B (mof2xmi-rtf)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

Annex B is only described as an agreement for OMG. Delete Annex B.

Resolution:
Revised Text:
Actions taken:
September 25, 2012: received issue
February 20, 2015: closed issue

Discussion:

The copyright to all OMG specifications (including this one) belongs to the organizations that wrote them. These  organizations are listed in this informative annex. Each of these organization's has given OMG an  irrevocable, transferrable, nonexclusive worldwide license to publish the specification and works derived from it,  under the terms listed in Annex B. OMG in turn uses this license to create a version of the specification that ISO  may publish, and gives ISO a non-exclusive license to do so.  Since the ISO document formatting conventions do not allow for declarations of copyright ownership near the  front of the specification (as is normal industry practice), all OMG PAS submissions (including this one) put this  information in an annex towards the end of the specification, as agreed with the ISO secretariat at the time of  OMG's first PAS submission in 1999.  The copyright ownership and usage license of the specification are as listed in this annex. Removing the annex  would not change this, and would deprive users of easy access to essential information about the copyright  ownership and licensing of the specification.  Ihis does not affect ISO/IEC's copyright ownership of the material it adds to the  specification.  Disposition: Closed No Change

Issue 18286: Fixed-point issues with the definition of default values for literals (mof2xmi-rtf)

Click here for this issue's archive.
Source: Model Driven Solutions (Mr. Steve Cook, steve-c(at)modeldriven.org)
Nature: Uncategorized Issue
Severity:
Summary:

The definition of LiteralBoolean in the XMI for UML1.5 includes the following:             <packagedElement xmi:type="uml:Class" xmi:id="LiteralBoolean" name="LiteralBoolean">          �          <ownedAttribute xmi:type="uml:Property" xmi:id="LiteralBoolean-value" name="value" visibility="public">            �            <defaultValue xmi:type="uml:LiteralBoolean" xmi:id="LiteralBoolean-value-_defaultValue"/>          </ownedAttribute>    �         So the default value for value, which is correctly specified as false in the model, is specified by the absence of a value attribute as �the default value for LiteralBoolean::value� in the XMI. This is circular and ill-defined.         One issue is with the XMI specification.  The rule that property values should not be serialized when they have their default value should not apply when those properties are being used to define default values for themselves.

Resolution: This needs to be addressed.
Revised Text: In section 9.4.1 replace the following constraint: � Properties whose values are the default values are not serialized. By: � Properties whose values are the default values are not serialized except where the value is being used to specify the default itself: specifically if it is the value of the property Property::defaultValue in a metamodel.
Actions taken:
December 5, 2012: received issue
December 5, 2012: received issue
February 20, 2015: closed issue

Issue 18379: XML Schema for Associations (mof2xmi-rtf)

Click here for this issue's archive.
Source: Adaptive (Mr. Pete Rivett, pete.rivett(at)adaptive.com)
Nature: Uncategorized Issue
Severity:
Summary:

Rule 7 in section 8.2.1 deals with serialization of association instances (links).  At the moment it uses <xsd:choice minOccurs=�0� maxOccurs=�unbounded�> for the ends. Though MOF is constrained to binary Associations, this would allow no, one, or even many ends to be serialized � which would never be valid.  It would be a lot cleaner and more sensible to use <xsd:all> which requires exactly 2 ends.  NB Rule 7 does not allow the use of XML attributes for the association ends, which would be allowed if the same reference were on an Object. I�m not convinced it would be useful (and it would not be Canonical XMI) but we should confirm that.

Resolution: Make the change as suggested
Revised Text: In rule 7 in section 8.2.1, replace: <xsd:choice minOccurs=�0� maxOccurs=�unbounded�>" 7b:AssnContents "</xsd:choice>" By: <xsd:all>" 7b:AssnContents "</xsd:all>"
Actions taken:
January 18, 2013: received issue
February 20, 2015: closed issue

Issue 18869: There was an error in the resolution for issue 16889 (mof2xmi-rtf)

Click here for this issue's archive.
Source: Adaptive (Mr. Pete Rivett, pete.rivett(at)adaptive.com)
Nature: Uncategorized Issue
Severity:
Summary:

There was an error in the resolution for issue 16889 in ballot 2.    That removed the following from rule 4e for XML schema production:    "xsd:attributeGroup ref=�linkAttribs�"    In fact the attribute group should not be removed but be enclosed in a xsd:complexType.    Recommended fix:         Replace last line:    "xsd:attributeGroup ref='linkAttribs'")*    By    "<xsd:complexType>    "xsd:attributeGroup ref='linkAttribs'    </xsd:complexType>         />" )*

Resolution: Agreed. Accept in principle
Revised Text: In clause 8.2.1, last line of rule 4e, After applying 16889 production 4e would become: 4e. ClassReferences ::= ( "<xsd:element name=�" //Name of Class-typed Property// "�" ( 4m:MinOccursAttrib )? ( 4n:MaxOccursAttrib )? "/>")* To resolve issue 18869 replace 4e. with the following: 4e. ClassReferences ::= ( "<xsd:element name=�" //Name of Class-typed Property// "�" ( 4m:MinOccursAttrib )? ( 4n:MaxOccursAttrib )? ">" "<xsd:complexType>" "<xsd:attributeGroup ref='linkAttribs' />" "</xsd:complexType>" "</xsd:element>")*
Actions taken:
August 13, 2013: received issue
February 20, 2015: closed issue

Issue 18968: The XMI.xsd has elements documentation and Documentation (mof2xmi-rtf)

Click here for this issue's archive.
Source: Adaptive (Mr. Pete Rivett, pete.rivett(at)adaptive.com)
Nature: Uncategorized Issue
Severity:
Summary:

The XMI.xsd has elements documentation and Documentation,    The presence of Documentation as well as documentation is a bug in the XMI spec: there is no purpose in having two elements for the same purpose; and this is meant to be derived from the model which has the lowercase �d�.         Proposed resolution: remove the Documentation element

Resolution: Make the change as suggested.
Revised Text: In clause 7.5.5, in the shown code, replace the last line, which reads: <xsd:element name="Documentation" type="Documentation"/> by <xsd:element name="documentation" type="Documentation"/> In file �XMI.xsd� remove the line� <xsd:element name="Documentation" type="Documentation"/>
Actions taken:
September 25, 2013: received issue
February 20, 2015: closed issue

Issue 19198: Absence of definitions of "XMI" and "MOF" (mof2xmi-rtf)

Click here for this issue's archive.
Source: Object Management Group (Mr. Claude Baudoin, cbaudoin(at)gmail.com)
Nature: Clarification
Severity: Significant
Summary:

The document, which is about a mapping of MOF to XMI, does not define the initialisms MOF or XMI anywhere in the documents, either in Chapter 1 (Scope) or in a glossary, which does not exist in this document.      Chapter 1 starts with "XMI is a widely used interchange format..." and ends with "MOF is the foundation technology for describing metamodels..." but there is no mention of what the terms actually stand for, a significant omission in a formal document.      One may also question the use of "MOF 2 XMI" in the title. While "MOF2XMI" may be a common way to create a meta-abbreviation for a relationship between two concepts denoted by abbreviations, there is little justification to eschew the grammatically correct "MOF-to-XMI Mapping" (with hyphens or spaces) in the document title. Using the numeral "2" is actually ambiguous -- does it mean "to" or does it refer to a version 2 of MOF?    Overall, this issue is more about casual editing than about correctness, but I believe it makes the specification weaker, editorially, than the usual OMG standard of documentation.

Resolution: Make the change as suggested
Revised Text: In section1, replace the sentence: XMI is widely used XML interchange format. By: XML Metadata Interchange (XMI) is a widely used XML interchange format
Actions taken:
January 28, 2014: received issue
February 20, 2015: closed issue