I’d like to complement the author(s) for their in-depth exploration of data necessary to describe a bridge structure.  The data relationships shown in the documentation appear mostly complete in showing the complexities that an XML standard must encapsulate.  That being said, I have a few areas I’d like to comment on.

GML Referencing

GML was established earlier as the basis for a TransXML standard, which I fully support.  I notice that GML referencing is not shown within these diagrams.  Is it correct to assume that a GIS metadata node with geospacial referencing is attached to the IDoBridge node?  Also, is the path geometry used to describe bridge components based on graphics primitives as defined in the GML standard?  

Simplifying The Model

In studying this model over the last two weeks, I’ve been trying to find a way to describe data in the simplest manner.  We need to find a balance between complexity and flexibility within the standard that’s developed, otherwise the complexity may make it impractical to implement.  

An important tool to help understand an implementation of the standard would be the development of an inheritance diagram.  This would help to organize common attributes between similar components.   

It should be possible to simplify the model by combining separate but related data types into one definition. For example, separate definitions exist for concrete, rebar, steel, pre-stress strands and timber materials.  Could the attributes of these be unioned together into one material definition with a type definition.  I’ve done this successfully with these material types, which are stored in a list and multiply-referenced by the components within the model and would be happy to share this with the group.

Floor Systems

I disagree with the organization of the floor system diagrams.  In my opinion, creating separate definitions for Girder-Floorbeam-Stringer, Girder-Floorbeam, and Floorbeam-Stringers are too restrictive and create additional complexity to the model.  Maybe I haven’t interpreted these correctly, but these definitions seem to imply that a homogeniety must exist within these definitions.  While this will work with many bridges, there are numerous hybrid systems in the real world that can’t be described by these definitions.  I believe it’s far better to describe the individual components of a structure and let the software that use these components assemble the model based on their geometric relationships to each other.  This not only simplifies the definition of the TransXML standard, but enables the flexibility to describe these special systems.