XMI12 — Reconsider XML attribute encoding of values in XMI 1.1

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.