Click for next page ( 32


The National Academies | 500 Fifth St. N.W. | Washington, D.C. 20001
Copyright © National Academy of Sciences. All rights reserved.
Terms of Use and Privacy Statement



Below are the first 10 and last 10 pages of uncorrected machine-read text (when available) of this chapter, followed by the top 30 algorithmically extracted key phrases from the chapter as a whole.
Intended to provide our own search engines and external engines with highly rich, chapter-representative searchable text on the opening pages of each chapter. Because it is UNCORRECTED material, please consider the following text as a useful but insufficient proxy for the authoritative book pages.

Do not use for reproduction, copying, pasting, or reading; exclusively for search engines.

OCR for page 31
32 SECTION 5 TransXML Process and Products This section describes both the process used to develop project team elected to adopt the NHTSA crash records schema TransXML schema, and the work products of the effort. that was released during Phase II of the TransXML project. Thus, eight new schema were developed for TransXML, and two external schema were adopted (NHTSA MMUCC 5.1 Schema Development Process XML and a subset of LandXML). A schema development plan was prepared based on the The schema development process involved the following analysis of gaps and opportunities presented in Section 4. This steps: plan identified the schema and sample applications to be Solicit participation in schema development by key stake- developed, defined the technical standards and processes to be holder groups for each of the schema areas through net- followed in order to provide consistency across the schema, working, e-mails, and establishment of a collaboration and established mechanisms for stakeholder involvement. website for TransXML. Stakeholder involvement is dis- Table 3 summarizes the work included in the schema cussed in Section 5.3. development plan. An initial activity in the plan was to con- Develop UML models for each of the schema areas in order duct an experiment to determine whether the XML encoding to gain consensus on data content and structure, and revise for TransXML should be based on the Geography Markup based on stakeholder comments. The UML modeling effort Language (GML). This would allow the TransXML effort to is described in Section 5.4. take advantage of a rigorous XML foundation, a structured Develop XML schema and sample applications. The process approach that enhances interoperability and tie-in to open used to generate the schema is described in Section 5.5; the geographic data standards. This experiment was conducted, content of the schema and applications is described in and after considerable debate, the decision was made to Section 5.6. adopt GML for new schema but to allow for inclusion of pre- existing, non-GML-compliant schema into TransXML. This approach struck a balance between establishing a consistent 5.2 Technical Framework framework for TransXML on the one hand, and avoiding for TransXML duplication of existing, accepted XML schema. Section 5.2 Schema Development Standards discusses the technical standards established for TransXML and the results of the GML experiment. Schema development standards were established to ensure A total of 10 data exchange topic areas were selected for consistency across the different schema efforts undertaken as detailed data modeling. For one of these areas--Geometric part of TransXML. They also provided for adherence to W3C Roadway Design--the schema development plan called for standards for XML schema and for the use of best practices which are generally accepted in the broader community of data modeling only, with no XML schema development. This XML schema developers. decision was made because of the large and well-established In order to define development standards for TransXML, user base of LandXML. In lieu of developing a new TransXML the following sources were consulted: schema, the project team recommended enhancements for consideration by LandXML.org. For a second area--Crash AASHTOWare Standards and Guidelines Notebook: Records--data modeling was completed, but a decision was http://aashtoware.org/docs/020820_Complete_Viewable_ made not to implement a TransXML schema. Instead, the S&G.pdf (or see AASHTOWare.org);

OCR for page 31
33 Table 3. TransXML schema development. Item Scope Comments A. GML Experiment Experiment done in order to make an informed decision about basing TransXML on GML. B. Geometric Exchange of roadway geometric design No XML produced Roadway Design information across design and survey enhancements suggested to (GRD) software packages, and for machine control. LandXML.org based on UML modeling. C. Design Project Exchange of design project pay item data Renamed from "Contract (DP) across design, cost estimation, and bid Pay Items" in original preparation software. Schema Development Plan. D. Area Features Exchange of area features data (e.g., wetlands (AF) locations) across GIS and CAD systems. E. Bid Package (BP) Exchange of construction bid package data between agency systems and contractor bid preparation software. F. Construction Exchange of information about the progress This was originally Progress (CP) of a construction project in terms of partial combined with materials pay item quantities placed. testing in the original Schema Development Plan. G. Materials Exchange of construction site installed Renamed from "Construction Sampling and quantities and materials used and tested Quantities and Materials" in Testing (MST) information from field data collection original Schema systems to laboratory systems and central Development Plan. construction progress tracking and contractor payment systems. H. Project Publication of construction project status Construction Status information to stakeholder information (PCS) systems (e.g., project web sites, partner agencies). I. Bridge Design and Conduct bridge structural analysis in Analysis (BDA) multiple software packages without the need to reenter data; compare analysis results across systems. J. Crash Report Exchange of crash data from police reports (NHTSA/Justice MMUCC to validation/processing systems and XML Schema adopted as archives; enables standard queries of crash part of TransXML). databases. K. Highway Exchange of highway inventory information Information Safety between inventory systems and safety Analysis (HISA) analysis software. Draft Federal XML Developers Guide (2002) http://xml. The following guidelines were established: gov/documents/in_progress/developersguide.pdf; aecXML Style Guidelines: http://www.iai-na.org/aecxml/ The Schemas will conform to the W3C XML Schema Rec- documents.php; ommendations: http://www.w3.org/XML/Schema; LandXML Detailed Documentation: http://www.landxml. Use of attributes within TransXML schema will be limited org/spec.htm; to conveying metadata about elements that are relevant JusticeXML naming conventions training slides: http:// only within the local scope of the element and are not likely justicexml.gtri.gatech.edu/workshop/Day2/9_Naming. to require further extension or parsing; pdf; and New TransXML schema will avoid duplication of existing GML: http://www.opengeospatial.org/docs/02-023r4.pdf-- elements of related schema that are currently in wide- Section 8. spread use through use of inclusion methods;

OCR for page 31
34 The most appropriate and restrictive data types will be can develop domain-specific application schemas. A GML used for element types and attributes; schema follows the W3C XML schema standard so all GML- A default namespace will be used to avoid the need to qual- compliant schema are also XML-compliant and can be vali- ify all element types and attributes with namespaces; dated with available XML tools. GML was developed by the The temporary namespace placeholder: "http:/www. Open Geospatial Consortium (OGC) and is a draft ISO stan- transxml.net/schema" will be used as the default namespace dard within the TC 211 191xx family of GIS-related stan- in the development of TransXML schema; dards. GML is the format for request and response messages All element names will be self-explanatory and meaningful for OGC Web Feature Services (WFS), which means that a to subject matter experts; variety of web applications for querying and serving geo- Plural case shall only be used for element names that rep- graphic data from a variety of sources are being designed to resent lists. Otherwise, singular case shall be used; understand GML. Upper Camel Case will be used for schema elements and Even though GML is clearly a product of the geospatial data types (e.g., "UpperCamelCaseElement"); data community, it is not only a markup language for geo- Lower Camel Case will be used for properties (e.g., "lower- graphic data. It provides an equally valid approach to XML CamelCaseProperty"); encoding for applications that have no geographic content. Schema component names will not contain Underscores (_), It claims to be an "XML-based mark-up language used to Periods (.), and Dashes (--); encode information about real-world objects [features]." These Schema element and attribute names will not use abbrevi- features can be concrete (tangible) like roads and bridges or ations, unless there is agreement among stakeholders that abstract like property or jurisdictional boundaries. GML pro- the abbreviations are widely understood and that they are vides a standard way to represent features, and properties necessary for conveying the element meaning; and of these features, which can include (but does not need to Schema element and attribute names should avoid the use include) information about their location and geometry. For of acronyms, unless the resulting names would be unrea- example, GML can be used to provide multiple representa- sonably verbose and/or the acronyms are nationally recog- tions of a roadway--its abstract characteristics (e.g., func- nized. If acronyms are used, they will be spelled out within tional classification), its location in space and along a longer schema annotations. route, and its horizontal and vertical alignments. The feature- centric approach supports data exchange across the enter- Even with adoption of the schema development standards prise because it allows for objects (such as roads) to have described above, the W3C XML Schema specification leaves geometrical representations of different types and at differ- considerable room for structural and stylistic differences across ent levels of precision, supporting a variety of applications schema developers. Also, it was apparent the schema in the (including inventory, GIS, and CAD). transportation field needed to make use of data elements that The guidance and structure provided by GML results in are required in other application areas--most notably for loca- more uniform schemas which are more human readable and tion, but for other elements as well. The research team felt predictable for software processing. The tradeoff to be made strongly that associating TransXML with an existing XML effort in adopting a foundation such as GML (or GJXDM for that that provided a consistent technical framework, including matter) as the basis for TransXML is the additional complex- foundational elements, would provide a leg-up for TransXML. ity for schema developers and overhead imposed on the XML The GML was identified as the most promising base for files themselves. In order to explore this issue, an experiment TransXML. The other option would have been the Global was conducted which involved developing parallel XML and JusticeXML Data Model (GJXDM), which has been emerging GML schema, instance documents, and extraction programs as a foundation for XML efforts in the Justice, and more for a candidate application area. The results of this experi- recently, Homeland Security communities. While either choice ment are provided in Appendix B. Key conclusions of this would have been beneficial for TransXML, GML was consid- experiment were as follows: ered to be better aligned with the types of schema to be pro- duced under TransXML. In particular, it provided better Use of GML required less effort in developing schemas than treatment of information describing physical objects and their straight XML because standard, predefined GML types properties (including geographic location), as well as consis- provided a foundation upon which to build TransXML- tency with adopted open geospatial standards. specific types. These include features, xlinks, basic types (for measurements, codes, etc.), geometry, topology, ref- erence systems, temporal, units of measure, and styles. Geography Markup Language The GML application schema was easier to read than the The GML is a set of XML building blocks designed to be a straight XML schema. This is because the GML schema was foundation on which specific industries, like transportation, less cluttered with basic type definitions. The GML object-