Preferred Use of the measure Attribute

[hesrah]

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

We have the units list 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:

• <property ... measure="IfcLabel">
       (with or without a base restriction in the value element)

or

• <property ... measure=""> (empty string for measure attribute is allowed with the current XSD)
      ...
    <ids:value>
          <xs:restriction base="xs:string">
           ...

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.

[Moult]

What's the disadvantage of requiring measure="IfcLabel"? Surely that is desirable to standardise properties between IfcLabel, IfcText, IfcIdentifier, etc.

I believe option 1 is the intention, as shown in the test cases.

[aothms]

I think these are three questions. Maybe some of these already came up in meetings. Apologies in that case.

I think at some point it was also discussed to rename measure to sth like datatype to remove part of the confusion to what extent a label is a measure. But ultimately we have to regard measure as a selection over the defined types https://standards.buildingsmart.org/IFC/RELEASE/IFC4/ADD2_TC1/HTML/link/alphabeticalorder-defined-types.htm

The second question relates to the XMI-base <-> IFC defined type mapping. I'm not sure if I'm a fan, but if we rely on this it also really needs to be formalized. Especially with things like dates/times/binary/logical where there isn't a single clear candidate or where there are multiple.

Then the third question. If both of these are kept, what is the preferred approach in various cases. Or should we eliminate one of the two approaches.

My preference would be to keep things explicit and require specifying explicit IFC types. If a user doesn't want to care about IfcLabel vs IfcText then the IDS authoring tool will have to help him to specify a IfcLabel|IfcText pattern. I would not prefer to keep using xml restriction bases for constraining property types.

[hesrah]

Sorry if this has already been discussed before. Apparently there wasn't enough discussion. :grin:

I agree with @aothms on most points.

@Moult: It is a mixture - both notional and with regards to content - of measure information (physical dimension, a semantic question) with data type information (a data-technical question). And we have two methods to do the same (measure attribute vs. XML restriction with base). If we want everything to be as uniform and consistent as possible, it's a hindrance.

First it would be more consistent with a name change. I suggest ifctype (not just datatype) as name, because the information is directly and always about IFC.

I understand the discomfort with the XML restriction with base. And I would never use both at the same time. My current favorite (for a future release) is to rename measure to ifctype and make this attribute optional. With the following convention:

• The IDS attribute should be preferred over the XML rextriction with base. If an IFC type is specified for a property, that should be specified without a XML restriction.
• XML restriction with base is used only when measure/ifctype attribute is omitted and only when required. So e.g. for currencies, possibly Q_COUNT, Q_AREA etc. (or a uniform mapping to IFC types is also agreed for the Q_...-types),
• but e.g. not for properties with enumerations. For this the measure/ifctype attribute as well as the XML restrction with base is omitted. It is sufficiently defined by XML restriction enum elements.

Maybe more conventions are needed. The goal should be minimal specification: as short as possible, as much as necessary.

[MatthiasWeise]

My interpretation is that measure is mandatory according to the IDS schema and has to stick to IFC Defined types (see link in documenation including IfcLabel, IfcText, IfcBoolean, IfcMonetaryMeasure etc.).

BTW: There is discrepancy in the property facet documentation (Data type) and the IDS schema (measure). It would be nice to stick to same wording.

Enumeration values seems to me no exception from above rule. They might be IfcLabel in most cases we know, but technically could have any measure/datatype from IFC.

I am not happy about using base restriction as an option.

Quantities seems to be some weird exception. I would expect that:

• we can ask for IFC base quantities using their Qto name + IfcXxxMeasure representing the correct quantity (IfcLengthMeasure for Q_LENGTH etc.)
• user defined quantities are always expected to be delivered as property

My conclusion: Improvement/harmonization of documentation suggested.