Usage of the Attribute facet for referencing attributes

[fissim-at]

Hi,
I tried to use the attribute facet to define which entity should be referenced by an attribute. For example, defining that the RelatingSpace attribute of IfcRelSpaceBoundary2ndLevel must be an IfcSpace (https://ifc43-docs.standards.buildingsmart.org/IFC/RELEASE/IFC4x3/HTML/lexical/IfcRelSpaceBoundary2ndLevel.htm):

<specification name="Specification 1: IFCRELSPACEBOUNDARY2NDLEVEL" ifcVersion="IFC4X3_ADD2">
    <applicability minOccurs="1" maxOccurs="unbounded">
        <entity>
            <name>
                <simpleValue>IFCRELSPACEBOUNDARY2NDLEVEL</simpleValue>
            </name>
        </entity>
    </applicability>
    <requirements>
        <attribute cardinality="required">
            <name>
                <simpleValue>RelatingSpace</simpleValue>
            </name>
            <value>
                <simpleValue>IfcSpace</simpleValue>
            </value>
        </attribute>
    </requirements>
</specification>

The IDS documentation states that only enumerated attributes in the documentation might be specified (because the others are inverse ones). However, the enumerated ones have again two types: ones with explicit values like Name or Description and ones with references to other entities, like for the RelatingSpace attribute. It seems IDS only allows attributes with explicit values. The example above does comply with the IDS schema, but the IDS audit tool, for example, does not allow it.

Is the attribute facet intended to be used for this case?

Thanks!

[CBenghi]

Edited for clarity

I agree with the intention.

I think that marking optional attributes as required is expressive, important, and feasible withing the data structure of 1.0.
Type constraining, however, would feel like a horrible hack at this stage for 1.0 (and probably 1.1 too).

With regards to marking optional attributes as required:

• every direct attribute should be valid, whether they point to a value (e.g. IfcLabel) or reference type (e.g. IfcSpace).
• value constraints should not be valid for reference types (e.g. RelatingSpace), and any value specified should trigger an audit tool error.
• When applied to reference types, the facet would mean that the model value should be not-null and not empty (e.g. RelatingSpace cannot be null), but no further constraint on its type or value.
• the audit tool should be changed to ensure that we have no redundant facets, and trigger an error if the attribute is marked as required in the schema (i.e. non optional) and no value constraint is specified.

I think that documentation changes should be enough to clarify implementation.
If this is agreeable, we need to:

• decide if we target 1.0 or 1.1, and
• ensure that it's supported in audit tooling.

[aothms]

• you could argue that a check for value identity and type-of semantics in a single field is not so pure
• age old question will come up on supporting inheritance or not
• many such values are lists of sets so the behaviour there needs to be considered (can be the same as elsewhere: applicability ANY, requirement ALL)
• the audit tool will need to check whether the requirement does not contradict the specification
• we'll need test case coverage
• you could argue that a proper recursion approach is more pure, so that we can use the existing entity facet and also constrain maybe it's values or other aspects

All in all, I would be very careful to slide this into 1.0

[CBenghi]

@aothms,
I agree with you completely... I posted a comment with the same sentiment on #448, and I missed to clarify it here. Apologies for the confusion.
I will edit my comment to remove the blunder.

typing constraints would not fit adequately in the current data structure, this cannot be addressed in 1.0 unless with a terrible hack.