I reviewed this document carefully and found it to be quite thorough and well explained. It is also accessible to readers unfamiliar with XML, as it includes a line by line walk through the XML examples with supporting documentation at every step. The key elements of GML and the intent behind them (e.g. object-property model, strong-typing) are well understood and convincingly presented in this report with explicit side-by-side samples of GML and (more general) XML.
The results of the GML experiment have conclusively demonstrated the following:
That TransXML developed schemas and schema elements can be encoded using either the GML process or standard XML encoding processes.
Using either method of encoding XML documents results in valid and extensible XML schema.
That reuse of already created XML schema elements can be easily be incorporated within newly developed TransXML schemas.
The experiment successfully demonstrated the reuse of non GML schema elements. AecXML elements were the standard xml elements used in the example schema.. There are many more sources of XML schema elements available for reuse. For example the following schemas are currently available for element reuse, JusticeXML, ITSXML, GML, G-MXL and LandXML. Each of these schemas has been developed to solve a specific vertical transportation need are excellent candidates for reuse within TransXML
GML is the only existing schema encoded using GML, will reuse of the other schema components cause a consistency problem when reused in TransXML?.
I believe the GML experiment has proven that either method of encoding, standard XML or GML will result in a technically workable solution.
The question that I ask at this point is simple, should TransXML be dependent and therefore based on GML?
The positives:
GML does offer existing schema components that are designed for the Geospatial business area. GML includes a standardized structure, style and name conventions which makes working with related schemas easier. GML is very extensive in the GIS and mapping spaces.
The negatives:
Existing transportation related schemas or not developed using GML encoding, such as ITSXML CrashRecordsXML, AecXML, JusticXML. These xml development efforts will continue to develop and expand within there vertical business spaces. This makes recoding these existing schemas in GML impractical do to continual developemnt of the original non GML schema. The OGC, the governance organization controlling GML development has a cost associated with membership and voting rights, given that, who will represent TransXML and who will finance the TransXML membership fees? Currently there are only a few existing software products supporting the current GML standard. The software products in the Civil design space currently support standard XML, not GML
Are the benefits of using GML as the framework for TransXML greater then the drawbacks?
Will the transportation software industry will accept the new direction toward GML, forcing them to recode existing applications that do not support GML elements?
I have concerns about making the deciding to develop the TransXML family of schema using the GML framework.
In closing I need to say, I feel that the TransXML family of schema is too broad for a framework design for GIS and mapping.
Steve Brown P.E.
Nebraska Department of Roads
Where is the experiment document located. I could not locate it.
Regards
Kannan
In the GML Working Group Documents area: http://www.transxml.net/GML+Experiment/Group+Documents/default.aspx
The experiment answers most of my questions about the technical feasability of using GML for TransXML development.
Is perception still a problem for acceptance? If the endeavor is perceived to be the subordination of all transportation data to a geographical perspective, supported by only certain vendors, then it will have difficulties in succeeding. On the other hand, if the emphasis is placed on Transportation data (only using GML as a convenience because of its object oriented framework and geographical constructs) and a broad base of vendors show interest, then there is more reason for optimism.
Assurance in the following areas (some of these have been addressed by the experiment) would help in making me feel more comfortable with TransXML's use of GML.
1. Show that communication performance and storage demands will not be severly impacted by use of GML schema and framework as opposed to other schema solutions.
2. Show that there will be little addition to development complexity and that XML data may be read and written in accordance with GML Schema with as much ease as any XML Schema and using the same development toolsets.
3. Provide XSLT programs for transforming LandXML elements into their TransXML counterparts. This is needed since those producing LandXML data, will continue to do so until there is a viable alternative and a means to get there.