Revit to gbXML - What does the window want to be?

As I was finishing my tutorial on manually placing shade devices as part of Revit's model envelope, I stumbled across this rather interesting "feature" that was exhibited while translating geometry into the gbXML file format. But before I continue to describe that particular Revit to gbXML behavior I need to make a correction to a statement in my previous article where I was testing Revit's ability to model shading devices by using In-Place families.

"Shading devices, constructed or planted, exterior or interior, can be approximated in Revit's BIM model via the persnickety use of a variety of modeling objects, but within Revit Architecture there is no identifier that designates any such improvisation as a valid gbXML compliant Shade surface. Someone might ask, but what about using a roof or a slab family to create exterior shading devices? Sounds like a good idea, but unfortunately to export such an element, the same one should be a part of a room bounding enclosure."

I need to praise Kyle Bernhardt for pointing out that this statement needs to be revised as follows: In Revit Architecture one can use Floors or Walls (stick with generic) to represent the shading surfaces. The Walls and Floors that are of the System Family type will get exported, but if you attempt to model them as In-Place families they will be ignored.
This means that any articulated solid extrusion made as an In-Place Wall or Floor will not be exported to the gbXML file.
Nevertheless in order to successfully export the objects mimicking Shading surfaces into the gbXML file, the warning message stating that a particular Room Bounding element is ignored should be disregarded and one can proceed with saving a new gbXML file.
Now back to glazing.
In order to test the available Window families and their corresponding operational (descriptive) parameter within the Revit Building Model, place an array of different window families along one wall in a sample model in order to see if the translated output will properly identify these windows according to the Window Type identifiers that are outlined within gbXML schema version 0.34.
Those Window type identifiers are as follows:

• FixedWindow
• OperableWindow
• FixedSkylight
• OperableSkylight
• SlidingDoor
• NonSlidingDoor
• Air

When building a model, if you resort only to Window families for facade apertures it really does not make any difference what type (Casement, Fixed, Awning, Glider etc.,) is used, as all of those will be translated with the "OperableWindow" gbXML type identifier.
The opposite in this glazing interpretation is that all of the Wall Family based glazing (Curtain Walls, Storefronts) is always translated with the "FixedWindow" gbXML type identifier.

The ability to eloquently articulate glazing performance in any building submitted via gbXML for analysis can not be regarded as accurate if the designer does not have the utmost control over the ventilation character of glazed surfaces. Unfortunately, within Revit Architecture we do not have the capability to designate windows operational descriptor, which means that the Curtain Wall family based glazing will always be simulated as non operable, whilst the Window family based glazing will always be characterized as operable type glazing.

One quick way to remedy this is to identify an element's ID and use it's value to parse and edit the gbXML file before is submitted to Green Building Studio for further analysis.

To mimic the sentiment of people that are trying to use Revit Architecture for Building Performance Analysis, it is quintessential to make some functionality changes to Revit's Room Object and make it behave more like the eSpace objects in Autocad Architecture where all of the relevant gbXML type identifiers can be directly assigned to the analytical space and its bounding elements such are walls and openings.