Use only simple string to define attributes

[pasi-paasiala]

In contrast to properties, attributes are defined in the schema, so their names and numbers are set. Therefore, it makes very little sense to be able to specify attributes with patterns or enumerations as is done in some examples:

• https://github.com/buildingSMART/IDS/blob/master/Documentation/testcases/attribute/pass-name_restrictions_will_match_any_result_3_3.ids
• https://github.com/buildingSMART/IDS/blob/master/Documentation/testcases/attribute/pass-an_optional_facet_always_passes_regardless_of_outcome_2_2.ids
• https://github.com/buildingSMART/IDS/blob/master/Documentation/testcases/attribute/pass-name_restrictions_will_match_any_result_3_3.ids

Also the cardinality for attributes is meaningless.

[Moult]

I recall attribute regexes were useful in some of the more annoying situations like LayerSetName vs Name.

It also has usecases in schema differences.

Why is the cardinality for attributes meaningless?

[pasi-paasiala]

There are very few useful attributes in IFC. Most of the expected use cases deal with things like property sets and classifications. That's why I'd prefer to keep the attribute implementation as simple as possible. The effort to write LayerSetName instead of using regex is small in comparison to supporting this in multiple implementations.

The current schemas are compatible, aren't they? Things are only added, so I don't understand the point of schema difference use cases.

In my opinion, you can only set requirements for an attribute value. Whether there is an attribute or not depends on the schema and not on the user. That's why I think cardinality is meaningless.

[aothms]

Schema compatibility in ifc predominantly concerns spf exchange. Attribute names are actually somewhat fluid. Sent from a mobile device. Excuse my brevity. Kind regards, Thomas Op di 25 apr. 2023 07:30 schreef pasi-paasiala ***@***.***>:

…

There are very few useful attributes in IFC. Most of the expected use cases deal with things like property sets and classifications. That's why I'd prefer to keep the attribute implementation as simple as possible. The effort to write LayerSetName instead of using regex is small in comparison to supporting this in multiple implementations. The current schemas are compatible, aren't they? Things are only added, so I don't understand the point of schema difference use cases. In my opinion, you can only set requirements for an attribute value. Whether there is an attribute or not depends on the schema and not on the user. That's why I think cardinality is meaningless. — Reply to this email directly, view it on GitHub <#156 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAILWV6SRWQYTNYC553535DXC5OQHANCNFSM6AAAAAAXJCVY6A> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[TLiebich]

schema compatibility in ifc also applies to ifcXML (if used), so I agree with Pasi. In case of attributes (mainly "Name", "Description", "LongName", and a few others) both the attribute name and the attribute cardinality are fixed in the schema and no use for wildcards or other cardinality bounds. So requirements for attributes are only useful for its value, not for the attribute name.

[Moult]

A note that the cardinality may be fixed in the schema, but that's a separate thing to the cardinality in IDS.

For example, the cardinality in schema might be optional, but the IDS might say "It is required for this to be filled in" or "It is prohibited for this to be filled in".

[pasi-paasiala]

The cardinality for attributes then can only be min/max = 0 or min/max = 1. Or should cardinality be applied to the value of the attribute, for example, if it is a list, then you could require that it has at least three items? I wonder, if there are any list attributes?

[Moult]

The cardinality for everything, not just attributes, can either be required, optional, or prohibited only. IDS as far as I'm aware has no scope right now for checking cardinality in the full sense of "there must be N items"

Note that handling lists is also covered in the test cases.