XMI 1.2 MAILINGLIST Avatar
  1. OMG Issue

XMI12 — Reconsider XML attribute encoding of values in XMI 1.1

  • Key: XMI12-50
  • Legacy Issue Number: 4062
  • Status: open  
  • Source: DSTC ( Stephen Crawley)
  • Summary:

    I want the XMI RTF to reconsider the XMI 1.1 change to the encoding
    of simple data type values. My experience and that of some others
    is that this makes implementation of XMI unnecessarily hard.

    Discussion:

    In XMI 1.0, the rules for encoding simple DataType values were
    relatively straightforward:

    • The value of an Attribute (whose type is a simple type) is
      represented as the text content of the Attribute's element,
      except for booleans and enums which are represented using
      the xmi.value attribute.
    • An embedded simple value (e.g. in a any, struct field, etc) is
      represented the same except that boolean and enum values are
      represented using the XMI.enum element.

    This is pretty straightforward ... apart from the inconsistent
    handling of boolean and enum.

    In XMI 1.1, the rules changed so that the XMI document producer
    could put values of simple DataTypes into the xmi.value attribute.
    The purported aim of this change was to allow more compact XMI
    documents to be generated. [I woould argue this is a bad reason
    for this change. Standard text compression algorithms would give
    ten-fold better compaction than tinkering with XMI encoding.]

    Unfortunately, this change has some consequences that were not
    apparent at the time:

    1) The rules for encoding values of Attributes got more complex.
    For example, with character and string values, you apparently
    need to see if the value contains 'problem' characters before
    deciding whether to encode them as attributes or elements.

    [It does not help that the XMI 1.1 does not mention this. It
    doesn't even bother even list the DataTypes that could be
    encoded as XMI attributes!]

    2) The rules for decoding values are similarly complex. Indeed
    more so, since the decoder cannot predict what choices the
    encoder made.

    3) XMI 1.1 value encoding is apparently problematical for XMI
    consumers that are implemented using XSLT. It has been
    reported that having to look for an Attribute value in
    two places is a serious problem.

    [The counter argument that XMI was not designed to be used
    with XSL is bogus IMO. We should be supporting a wide spectrum
    of modes of use for XMI. Besides, the XMI 1.1 spec specificly
    mentions XSL in 4.3.6 with the implication that it is, or
    will be supported!]

    4) Having to look in two places will be problematical for conformance
    of hand-built XMI consumers. A hand built consumer will typically
    be tested against one XMI producer which makes one set of choices
    on encoding Attributes. If the consumer encounters an XMI document
    generated by different producer software, the chances are that it
    will break.

    These problems – particularly 3) and 4) – are sufficiently serious
    that we should review the decision that XMI 1.1 made to allow simple
    DataType values to be expressed in two ways.

  • Reported: XMI 1.1 — Mon, 20 Nov 2000 05:00 GMT
  • Updated: Wed, 11 Mar 2015 11:12 GMT