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 65 forks source link

IFC parent types #184

Closed fbosche closed 1 year ago

fbosche commented 1 year ago

I have been testing my IDS in which I set some property requirements for IfcBuiltElement entities. In my IFC file I have IfcBuildingElementProxy elements and the IDS check fails with them. But, if I change the IDS requirement to apply to entities of type IfcBuildingElementProxy then it works. Isn't it possible to use parent types?

andyward commented 1 year ago

Not in the current version, although there has been various discussion about it e.g. #146 #86 . Hopefully it will get addressed after the 1.0 release.

So currently you have to use an Enumeration of all the types (or use a Pattern maybe?)

fbosche commented 1 year ago

I was looking at the XDS file yesterday evening and realised that inheritance was clearly not there. In fact, I've now also looked at the thread you pointed it and it would indeed create further challenges for implementers as they would have to do inheritance "look-ups in the schema. Enumeration is not too bad for now. I'll try to implement this now. Thank you very much.

andyward commented 1 year ago

II will say we've actually implemented type inheritance in our xbim IDS validator (Obviously it's non-standard behaviour so it's on a swich). It was pretty trivial to implement (in .NET at least) - I'd suggest the inheritance requirements in Classification facets and some of the edge-cases in PSet & Material facets may be the more challenging features for implementors.

Most implementors will have some kind of IFC schema hierarchy datamodel they can use, so I'd not use implementation challenge as reason to address type inheritance. The way I read the ethos of IDS is it's supposed to make it easier on the specifier and leave the complexity to the implementors

fbosche commented 1 year ago

Thanks. I actually used the xbim validator yesterday and noticed the button for inheritance, which I thought was going to do this nicely for me. However, it didn't seem to work. Once, it created a restriction group, but then only listed IfcBuildingElement in the enumeration, and none of the types inheriting from it. In other attempts, it didn't even create any restriction group and just kept the IfcBuildingElement type as singleValue (not clear what I did differently with those. Anyways, this may be more for discussion on the xBIM forum.

andyward commented 1 year ago

I would ping this discussion over in the direction of @CBenghi 's https://github.com/CBenghi/Xbim.Xids repo. But I think Subtypes are just implemented in a non standard JSON format of IDS, not the XML BS standard. I don't believe @CBenghi 's app is supposed to explode the parent type into all possible sub classes - although I suppose that could actually be a pragmatic IDS1.0-compatible workaround for the lack of sub-types (given you know the Ifc Schema)

What I was taling about is we've a separate verification library that can do this 'explosion' of parents to child entity types at the checking stage not the IDS authoring. Means you could do things like apply to entities and subtypes matching pattern 'IFCFLOW.*'

Suggest we close this here and pick up over in XIDS for any further discussion ;)

fbosche commented 1 year ago

Thanks. Yes, you may close this indeed. Meanwhile my next question may actually go to BlenderBIM IfcTester. But, I'll definitely keeping an eye on all this.

fbosche commented 1 year ago

Closing now