buildingSMART / IDS

Computer interpretable (XML) standard to define Information Delivery Specifications for BIM (mainly used for IFC)
https://www.buildingsmart.org/standards/bsi-standards/information-delivery-specification-ids/
Other
215 stars 66 forks source link

Conditional PartOf specifications #379

Open atomczak opened 2 days ago

atomczak commented 2 days ago

Discussed in https://github.com/buildingSMART/IDS/discussions/341

Originally posted by **andyward** September 12, 2024 I'd like to write a specification that implements the requirement that **All spaces belonging to a BuildingStorey '01' should have their space names matching '01-.*'** (or the converse requirement: **Spaces named like '01-.*' must be part of a BuildingStorey with Name '01'** ) I'm struggling to see how I could do this in IDS1.0. I was hoping to be able to do this with the _partOf_ facet and using **RelAggregates** but there's no obvious way to apply a requirement to the 'child' side of the relationship. e.g. ```xml IFCBUILDINGSTOREY Name 01 IFCSPACE ``` Any ideas? or is this a usecase to consider for a future IDS? I'd imagine similar use cases for things like ensuring components are in the correct IfcSystem (by classification, name etc).
atomczak commented 2 days ago

How about this https://github.com/buildingSMART/IDS/pull/380? Simply allow any facet in PartOf, except PartOf itself, with a minimum of one entity. The implementers' agreement would be that those subfacets apply to the PartOf entity itself. @andyward

NickNisbet commented 2 days ago

Before going down this route, lets do a review of the overall syntax and back/forward-referencing. Otherwise we could be revisiiting this to add more and more syntaxes for ever.

andyward commented 2 days ago

How about this #380? Simply allow any facet in PartOf, except PartOf itself, with a minimum of one entity. The implementers' agreement would be that those subfacets apply to the PartOf entity itself. @andyward

Nice- Looks like it would satisfy the requirement, and seems simple and non-breaking for a 1.1 release. Not sure about the wider syntax review - but that feels like an IDS2 thing if we're making major changes (e.g. Exclusions etc)? Because we're re-using the existing facetTypes this would pick up any future changes anyway?

atomczak commented 2 days ago

I agree with @andyward; this is an acceptable minor change for 1.1, unlike any bigger syntax changes. @NickNisbet, can you document the exact changes you want to propose in Discussions? (unless it's already there)