XMI 2.4 RTF Avatar
  1. OMG Issue

XMI24 — Impractical representation of structured datatypes

  • Key: XMI24-18
  • Legacy Issue Number: 8884
  • Status: closed  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    Section 7.8.7 and example in 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.

  • Reported: XMI 2.0 — Tue, 28 Jun 2005 04:00 GMT
  • Disposition: Resolved — XMI 2.4
  • Disposition Summary:

    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.

  • Updated: Fri, 6 Mar 2015 20:59 GMT