Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Shortcoming for validation of PredefinedType setting in entity facet #214

Open
MatthiasWeise opened this issue Oct 26, 2023 · 5 comments
Open
Assignees
Labels
documentation Improvements or additions to documentation
Milestone

Comments

@MatthiasWeise
Copy link
Contributor

I was wondering if correct use of the predefinedType is checked by http://www.xbim.it/ids.
Obviously not, because current agreement with USERDEFINED does enable to check misspelling of predefinedType.

@CBenghi
Copy link
Contributor

CBenghi commented Oct 26, 2023

Hi @MatthiasWeise,
Constraining the PredefinedType is something I originally added, but have since relaxed.
Indeed the code infrastructure to enforce the closed list is still in the tool, but the agreement in the group is that we must allow for the selection of user defined values.
What I can easily do is to add a warning to the log, that notifies of non-standard strings, if that helps.
Would that be useful?

@MatthiasWeise
Copy link
Contributor Author

MatthiasWeise commented Oct 26, 2023

Yes, a warning would be good to avoid misspelling of predefinedType.
Actually, I wanted to check if USERDEFINED is allowed or not. I would argue that we should allow USERDEFINED, and then to check that predefinedType = USERDEFINED and objectType can have any value.

@CBenghi
Copy link
Contributor

CBenghi commented Oct 26, 2023

However that would prevent us from selecting specific parts of the models that have a custom predefinedType, which does not sound right.
We do need a test case that deals with some predefined type configuration, if we don't have one yet. I'll have to check.

@CBenghi CBenghi self-assigned this Oct 26, 2023
@CBenghi CBenghi added the documentation Improvements or additions to documentation label Oct 26, 2023
@CBenghi CBenghi added this to the 1.0 milestone Oct 26, 2023
@MatthiasWeise
Copy link
Contributor Author

I was more thinking that we need both, USERDEFINED to be unspecific about what user defined type should be selected and to use any other value not being in the list of predefinedTypeEnums for a specific used defined type.

@andyward
Copy link
Contributor

Agreed, checking for any custom/USERDEFINED predefined type feels useful. This shouldn't preclude implicitly checking the ObjectType.

  1. Standard case: All Doors defined as TrapDoor (PredefinedType = TRAPDOOR)

Entity Facet:

  • IfcType: IFCDOOR
  • PredefinedType: TRAPDOOR
  1. User defined scenario All Doors defined as 'SecurityDoor' (ObjectType = 'SecurityDoor' [and PredefinedType = USERDEFINED])

Entity Facet:

  • IfcType: IFCDOOR
  • PredefinedType: SecurityDoor
  1. Edge case All Doors with any User-defined type (PredefinedType = USERDEFINED)

Entity Facet:

  • IfcType: IFCDOOR
  • PredefinedType: USERDEFINED

In particular, a use case might be: "All elements must NOT have a PredefinedType of USERDEFINED". That kind of test might help with #116, as presumably you could select applicable items with IfcFlowTerminal of Predefined Type 'DIFFUSER,GRILL' etc if you can exclude USERDEFINED and NOTDEFINED . This assumes implementations fall back to the Type to check the PDT - i.e [IfcAirTerminal]Type's PDT to filter the Ifc2x3 FlowTerminals.

It would also let IDS police the (mis)usage we sometimes see of IfcObject.ObjectType being defined when PredefinedType is NOTDEFINED - by combining an Entity requirement and an Attribute requirement.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
documentation Improvements or additions to documentation
Projects
None yet
Development

No branches or pull requests

3 participants