Home

Concepts of gbXML Schema Validation

validation (n.) - the process of determining the degree to which a model or simulation is an accurate representation of the real world from the perspective of the intended uses of *the model or simulation. * origins: 16th century Medieval Latin, validatus

This is the goal of validation, to determine the degree to which the gbXML is an accurate representation of a building, or set of buildings, from the perspective of the end user. And right there, we face a conundrum of sorts. The perspective of the end user varies from person to person, depending upon the type of simulation they wish to perform, and the constraints and inputs of the simulation tool which is being used. Since gbXML is a jack of all trades and should be ubiquitous in the transfer of information for any model, this can make validation tricky business.

To validate any XML file, gbXML.org decided to approach validation at the highest level of abstraction as three separate stages.

1. Is the XML valid XML?
2. Is the XML valid gbXML?
3. How accurate is the data contained in the gbXML files?

The first two checks are really quite general, and a great deal of programming resource has not been required to make it work. The concept behind these two stages is to ensure that the language in the XML is properly formatted. That is, spelling is correct, structure is correct, all tags are well-formed. gbXML.org has relied upon standard Microsoft libraries to check the gbXML against the latest XSD, and if errors are found, the libraries automatically generate errors that are thrown and then reported to the user. Passage of these two tests essentially assured that the file is essentially gbXML and is capable of being read by any standard gbXML parser.

Accuracy, part 3, is where the validator and its code base first begin to step beyond the dependencies of the XSD and standard tools to begin intelligently analyzing the gbXML, on behalf of the user, to determine whether it is sufficiently robust for simulation.

Up until the time of this writing (March 13, 2014) there have really only been one group of people who wish to consume and process gbXML, mechanical engineers and energy modelers, though the origins of gbXML is the serializers embedded in architectural CAD and BIM programs. Each of these groups have specific goals, due in large part to the tools they have chosen to use for their simulations. In some cases, engineers place a self-imposed need for accuracy which is not based in any statistical significance. Because gbXML is intended for audiences that have varying requirements of accuracy, and gbXML itself is inherently flexible, this can make validation seem complicated.

XML and gbXML Well-formedness Tests (stages 1 and 2)

Uses standard Microsoft libraries to check the XML tags for malformedness, and if the gbXML meets the requirements of the XSD.

The Phase 2 Validator - Space Element Tests (stage 3)

The Phase 2 validator is solely focused on validating gbXML as in the Phase 1 validator, with the additional checks of the geometry descriptions that are contained within the gbXML file format. Since all of this geometry information is contained within the Space and Surface Elements (and their children), the validator is designed to hone in on these elements and thoroughly review them.

Beyond checking for valid XML and well-formedness when compared to the XSD, the validator also performs the following checks. At the Space level of the document, for each Space found in the document:

• Are all required fields in place?
• Unique Space id test (this is a duplicate of the Phase 1 test)
  • all Space id attributes have to be unique
• Space surfaces Planarity tests
  • do the spaces contain ShellGeometry and SpaceBoundary elements? If so, check otherwise do nothing
• Space surface polygons winding in counter-clockwise order (this code is currently being debated and subject for review)
  • same applies regarding ShellGeometry and SpaceBoundary elements
• Space surfaces are all non-intersecting polygons (this code is currently being debated and subject for review)
  • same applies regarding ShellGeometry and SpaceBoundary elements as stated above
• do Space surfaces form a valid enclosure, i.e. – how watertight is the enclosure definition
  • we can only do these tests if either ShellGeometry or SurfaceBoundary elements are present

Since the ShellGeometry element and SurfaceBoundary element are optional in the Space definition as of the latest XSD, we’ve had to make special accommodation to only check them if they are present. There is not a requirement currently that requires both to be present in a Space element. Either one or the other can be present exclusively.

The Phase 2 Validator - Surface Element Tests (stage 3)

The Surface elements geometry descriptions are next checked after the Space geometry. For each Surface element:

• are all required fields in place?
• are all Surface id attributes unique? This is a requirement for gbXML
• does reported children Tiltand Azimuth InnerText match the Surface polygon's normal vector representation?
  • this should also work if the user puts in a CADModelAzimuth value (this code has not been started)
• Surface polygon coordinates planarity tests
• Surface counter-clockwise winding order tests (this code is currently being debated and subject for review)
• Surface polygons are all non-intersecting polygons (this code is currently being debated and subject for review)
• if there are SpaceBoundary elements defined at the Space element level, then the polygons describing both the Surface and SpaceBoundary should be identical
• do Surface elements form a valid enclosure, i.e. – how watertight is the enclosure definition
• there could be more optional checks that have not been started, like to determine if the surfaceType and adjacentSpaceId children make rational sense.