IDS
IDS copied to clipboard
buildingSMART
UPPERCASE instead of PascalCase in IDS?
Is there some reason to keep UPPERCASE instead of PascalCase for a class identification within the IDS specification, as shown in the Candidate Standard Report - January 2023?
There might be applications that are not schema-aware and only can go by the instance definitions from the .ifc file which is uppercase. I'm not sure how realistic that is, but that is what we discussed at the time.
I would at any time vote for PascalCase over uppercase when strings are concatenated parts. Any software can go from PascalCase to UPPERCASE but the reverse is not possible without consulting a schema. I believe it's even more important for predefined types then for entities.
the IFC specification for identifiers in EXPRESS is indeed not case sensitive, in ifcXML however it is. Also the candidate spec says that IDS should be applicable in principle also to other schemas (maybe gml, gbXML?) - and then all UPPERCASE ?
so yes, +1 from me as well.
Because of regexes in the patterns, implementers are going to have quite a bit of work to do, with any of the choices:
- for UX developers to produce a good readable UI,
- for implementers to consider all the XML/EXPRESS options.
- for the users to ensure that the files we exchange are meaningful and valid across various UXs/Checkers.
Just making strings UPPERCASE when saving from the UI is not enough, because we will have to include some logic to tell apart the metacharacters of regexes:
E.g.:
| \w | Matches any word character including underscore. This expression is equivalent to [A-Za-z0-9_]. |
|---|---|
| \W | Matches any non-word character. This expression is equivalent to [^A-Za-z0-9_]. |
PascalCase carries more information (PC to UC can be done, not vice versa), but that is also more error prone if end users are typing freely (especially in regexes), so UPPERCASE will probably result in fewer invalid IDS files.
@aothms, I think that the argument for applications that are not schema-aware, is weaker than it was in the past, since we have introduced attributeType, inheritance of properties through types, measures conversion and more.
The choice we make, I think, should depend on what makes most resilient ecosystem, from an end user perspective.
Personally, I think that making the tests case-insensitive would deliver the best user experience, but I acknowledge that it would be the most complex implementation, particularly for UIs.
@aothms, I think that the argument for applications that are not schema-aware, is weaker than it was in the past
I wouldn't disagree with that, I was thinking the same actually.
Personally, I think that making the tests case-insensitive would deliver the best user experience
That is also most inline with the express semantics. Express is case-insensitive.
I think most regex implementations have an option/flag to ignore case [0] [1]. So you wouldn't have to do case normalization on the pattern (potentially triggering changes when doing \W -> \w.)
I think there is a point for case insensitivity on schema names (what about pset and prop names?) but it's also potentially surprising when then model values are handled case sensitively (users might not always be able to tell the difference).
[0] https://docs.python.org/3/library/re.html#re.IGNORECASE
[1] https://learn.microsoft.com/en-us/dotnet/api/system.text.regularexpressions.regexoptions?view=net-7.0#system-text-regularexpressions-regexoptions-ignorecase
The group decided that for simplicity we can keep it UPPERCASE for version 1.0. This will need to be documented appropriately, and we can investigate if it is possible to add a restriction to the xsd schema.