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 32
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 33
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-
