Add choice for multiple auc:WallIDs within auc:Side

[macintoshpie]

No description provided.

[markborkum]

Introducing the xsd:choice element means that this would still be a breaking change for Audit Template, which would need to test the element being specified, and then either reject all auc:WallIDs elements or select the first auc:WallID for each auc:WallIDs element.

Also, from a philosophical perspective, I'm not sure if this change makes sense.

In BuildingSync, the "facility", "site", "building" and "section" concepts are descriptions of the interiors of surfaces in 3-dimensional space. We infer facts from the presence of XML elements, e.g., "there is a building within the interior of this surface" because of a given auc:Building element, and we infer part/whole relationships from the XML document object model, e.g., "this site is part of this facility" because a given auc:Site element is a child of a given auc:Facility element.

The "side" concept is a description of distinct slice of the surface for a "section" concept. We assert facts like "this side is touching a wall" by writing the auc:WallID element. Importantly, if we glue together the slices for each "side" concept for a given "section" concept, we recover the entire surface.

Q: If a "side" represents a distinct slice of a surface, then does it make sense for a "side" to be touching more than one wall?

Q: If "walls" of 2 or more different materials are stacked horizontally or vertically, such that each slice of the "wall" is distinct, then would it make more sense to have a distinct "side" for each distinct "wall"? Or, is "stacking" a new characteristic of the "wall" itself that should be defined by the auc:WallSystemType element?

[corymosiman12]

Hey @markborkum - I'll try to provide a few clarifications:

• Per the BuildingSync Geometry Reference, an auc:Side element would specifically refer to one of those 'sides', i.e. A1, B1, etc.
• We have mainly just considered this for the use case of auc:Section/auc:SectionType='Whole Building', i.e. we are trying to define the composition of the entire building envelope in a concise way. We originally thought this would be part of the auc:Building element, but the majority of the infrastructure is already defined at the auc:Section level, so we kept it there.
• The desire to have each auc:Side element be composed of multiple 'wall types' is the main reason for this addition. The intension is that multiple auc:Wall elements can be declared (i.e. Wall Type A with insulation value of R-18, Wall Type B with insulation value of R-12, etc.). These wall types can then be 'applied' to a single / multiple sides with a defined area of that side made up by that specific wall type.

This can basically all be summarized by the following graphic.

If we were to get really fancy, we would add capabilities to define how walls are related to one another on a side, however, that is out of scope for 211 Level 2 audit.

[corymosiman12]

lgtm

[markborkum]

@corymosiman12 Makes sense, thanks.

[macintoshpie]

@markborkum would you rather we just remove the choice and have users use auc:WallIDs? ie no option to just have auc:WallID as direct child of auc:Side

[markborkum]

@macintoshpie No. For the time being, please keep the xsd:choice element. From the Audit Template perspective, accommodating the xsd:choice element is the lesser breaking change (compared to refactoring Audit Template's current usage of the auc:WallID element).