Preferred Use of the measure Attribute

I have a question/discussion about the preferred use of the `measure` attribute in a `property` element.

We have the [units list](https://github.com/buildingSMART/IDS/blob/master/Documentation/units.md) in the documentation with the preferred values. And on the one hand, the `measure` attribute is mandatory. On the other hand, there are properties without units/physical dimension. For example, property values from an enum list are strings (`IfcLabel`), currency values are float numbers (`IfcReal`) or for quantities there is the datatype `Q_COUNT` (`IfcInteger`).
There is no formal strict domain for the `measure` attribute, so it's possible to use e.g. `measure="IfcLabel"`. But `IfcLabel`, `IfcReal`, `IfcInteger` etc. are not really measure types but data types. And for data types, we have the _XML_ data type restriction with `base`.

Now we have (at least) two ways to write an _IDS_ for a property with `IfcLabel` values:

- ``
     (with or without a `base` restriction in the `value` element)

or

- `` (empty string for `measure` attribute is allowed with the current _XSD_)
    `...`
    ``
          ``
          ` ...`

What is the preferred usage for _IDS 0.9.3_/_1.0_?

I think both are not very nice. The first variant mixes measure and data types. And with an additional `base` restriction the data type information is redundant. The second variant has an empty `measure` attribute, which I guess I no longer need to explain why that's not nice.

I propose for _IDS 1.1*_ to make the `measure` attribute optional (perhaps restrict its values to the pattern `"Ifc...Measure"`) and always specify elementary data types as an _XML_ restriction (with `base`) if the `measure` attribute is missing. So, for `IfcLabel` it would be the second variant without the (empty) `measure` attribute.

Start with Documentation/units.md and the current XSD, then compare the two `measure` and `value` patterns described for IDS 0.9.3/1.0. Review the proposed IDS 1.1 approach of making `measure` optional and using XML restrictions for elementary types; done means reaching and documenting an agreed preferred usage.

Written by the indexing model from the issue text.