TransXML: XML Schemas for Exchange of Transportation Data (2007)

Below is the uncorrected machine-read text of this chapter, intended to provide our own search engines and external engines with highly rich, chapter-representative searchable text of each book. Because it is UNCORRECTED material, please consider the following text as a useful but insufficient proxy for the authoritative book pages.

45 6.1 Introduction One of the objectives of NCHRP Project 20-64 was to define an appropriate mechanism for continued maintenance and development of XML schemas for transportation data exchange after the project is completed. This section presents the analysis of options for ongoing stewardship of Trans- XML. To develop a stewardship approach for TransXML, the research team first looked at existing models for XML stew- ardship in other domain areas. The team looked at their organization, funding, participants, and activities. Based on the existing models, and the experience gained during NCHRP Project 20-64, the research team developed a proposed mission statement for a future TransXML project, along with a set of goals and functions. Then, four options for future stewardship were identified and evaluated. Finally, a more specific 2-year implementation plan for TransXML was developed. In the remainder of this section, the name NCHRP Project 20-64 is used to refer to the initial TransXML effort that is the topic of this final report. The name TransXML Project is used to refer to a broader continuing effort that will ideally evolve out of the work from NCHRP 20-64. 6.2 Existing Models for XML Stewardship The following existing efforts were identified in order to understand the range of existing models for stewardship that could be considered for TransXML: • OASIS—The Organization for the Advancement of Struc- tured Information Standards (OASIS) is a global consor- tium founded in 1993 (originally as SGML Open) that works toward adoption of e-business standards. OASIS has established, well-defined mechanisms to support open standards development processes, including formation of technical committees, membership and participation requirements, voting procedures, and standards approval processes. Membership in OASIS is required in order to participate in technical committees. Membership fees in OASIS are $250 (for individuals), and between $1,000 and $5,750 for organizations (higher-cost sponsorship mem- berships are also offered). OASIS membership composition is currently 15 percent government and academic, 51 per- cent technology providers, and 34 percent users. Current government members are primarily from the legal/justice, homeland security, and defense communities. Examples of currently active OASIS technical committees include: elec- tion and voter services, electronic procurement, emergency management, and product life-cycle support. • Justice—The JusticeXML data model was developed jointly by the U.S. Department of Justice (DOJ)—Office of Justice Programs (OJP), and the Global Justice Informa- tion Sharing Initiative (Global). The U.S. Attorney General approved establishment of the Global Advisory Commit- tee (GAC) in 2000, to “ensure appropriate input from local, state, tribal, and Federal agencies regarding informa- tion sharing and integration within the justice commu- nity.” In accordance with the Federal Advisory Committee Act (FACA), the GAC’s charter is for a 2-year period (the current charter started October 2002). The U.S. DOJ pro- vides all support services for the GAC, and its operating expenses (for the 2-year charter period) were estimated at $2 million. The GAC appoints subject-matter Working Groups to research specific topics and prepare recommen- dations. The Global Infrastructure/Standards Working Group (ISWG) created the XML Structure Task Force (XSTF) to develop the Global JusticeXML Data Dictionary (GJXDD). This body involved a wide variety of stake- holders. The bulk of the technical development work was done by the Georgia Tech Research Institute (GTRI). • LandXML—LandXML is a nonprofit industry consortium formed in 2000 to support continued improvement to and use of the LandXML schema. There are about 300 members S E C T I O N 6 Future Stewardship of TransXML

representing government agencies, software vendors, engineering firms, and academic institutions. There is no membership fee, and LandXML operates on volunteer labor. An employee of Autodesk has been providing significant leadership and support for the effort. • GML/OGC—GML was authored by a private company (Galdos Systems, Inc.). The Open Geospatial Consortium (OGC) currently maintains the specification through an open working group process. Galdos staff lead this work- ing group and continue to make significant technical and marketing contributions. However, the OGC’s intellectual property policy requires that all contributors of technical material for adopted specifications provide a royalty-free license to any party that wants to use the specification (both OGC members and nonmembers). OGC is a not- for-profit organization founded in 1994, with the mission of advancing interoperability among IT systems that process geo-referenced information. OGC currently has roughly 250 members, from private industry, govern- ment, and academia. It has a staff of 13 and a 14 member board of directors. Membership in OGC ranges from $300 per year for local government staff (nonvoting member- ship) up to $50,000 per year for Principal Members (who can chair technical committees and receive support ser- vices from OGC staff). The OGC operates three programs: (1) the Specification Program, (2) the Interoperability Program, and (3) the Outreach and Community Adop- tion Program. The Specification Program houses work- ing groups that develop Implementation Specifications (e.g., GML). The Interoperability Program complements the Specification Program by organizing experiments, test beds, and pilot projects (e.g., Geospatial One-Stop, LandGML). The Outreach and Community Adoption Program undertakes activities to support widespread use of OGC specifications (e.g., strategic alliances, conferences, and seminars). • aecXML—The aecXML schema was originally developed by Bentley Systems, who spearheaded the formation of the aecXML industry consortium. Several working groups were formed to focus on topic areas including design, projects, procurement, and catalogs. The International Alliance for Interoperability (IAI) adopted aecXML in 2000. IAI is a pro- gram of the National Institute of Building Sciences, a non- profit organization. The purpose of IAI is to facilitate information exchange within the building industry. IAI has a staff of six, and a five-member management committee, and a 31-member board, consisting of government and pri- vate industry organizations. IAI’s membership fees range from $1,000 to $10,000. Technical activity is performed in working groups by members on a volunteer basis. Momen- tum for maintaining and improving the standards depends on the sustained energies of these volunteers. • TranXML/LogisticsXML—TranXML was developed by Transentric, a company specializing in outsourced rail car tracking. The intellectual property for TranXML was acquired in 2002 by the Open Applications Group (OAGi), a nonprofit industry consortium. OAGi was formed in February 1995 by a group of enterprise software vendors (including SAP and PeopleSoft). Its initial work was funded by these founders and focused on specifications for finan- cial transactions and supply chain integration. OAGi’s membership currently consists primarily of software vendors and manufacturing companies. A working group within OAGi is now using TranXML as an input to the development of a broader LogisticsXML schema. • ITS Standards Development—While not necessarily related to XML schema, mechanisms for ITS standards development also provide useful models for the TransXML stewardship investigation. Based on the national ITS architecture, several standards development organizations (SDO’s) are responsible for developing ITS standards through a consensus process. These SDO’s include: the American Association of State Highway and Transporta- tion Officials (AASHTO), the Institute of Transportation Engineers (ITE), the Institute of Electrical and Electronics Engineers (IEEE), the Society of Automotive Engineers (SAE), the American National Standards Institute (ANSI), the National Electronic Manufacturers Association (NEMA), and the American Society for Testing and Materials (ASTM). This work is done in a collaborative fashion. For example, there is an IEEE Incident Management Working Group which has been responsible for the 1512 family of stan- dards. Participants in this group have included FHWA, ITE, AASHTO, several state DOTs, public safety agen- cies, and ITS industry vendors. Cooperative agreements are also a frequently used mechanism; for example, a joint ITE/AASHTO steering committee was responsible for the development of the Traffic Model Data Dictionary (TMDD) and message sets for external traffic management centers (MS/ETMC2) standards. 6.3 Lessons Learned It is useful to summarize some key observations related to stewardship based on the experience gained during NCHRP Project 20-64. Focus on Value Added It was recognized from the project’s inception that sim- ply producing an XML schema will not guarantee that the schema will be adopted or that it will provide value, and sub- stantive stakeholder involvement in schema development is essential to success (where success is defined as a critical mass 46

of adopters resulting in collective time and cost savings). The stewardship function must therefore ensure that resources are being devoted to the most promising schema development opportunities—where value can be clearly demonstrated and widely understood. It must also devote considerable resources to communication—through multiple channels. Need to Coordinate with Related Standards Efforts The second observation is that the scope of TransXML touches many areas where schema and standards already exist, and therefore the future TransXML project must work within the environment of existing schema and standards development efforts that are now occurring within various communities: • Design/Survey—LandXML is an established interchange standard, with an established national (and international) stakeholder community. TransXML can participate as a stakeholder in LandXML, but cannot and should not control schema development in this arena. • Location Data—The OGC’s GML effort and the Geospa- tial One-Stop Initiative are defining open standards and XML encodings for geographic information. TransXML should be a consumer of these efforts, and not attempt to duplicate or conflict with the work that is occurring. • Safety—The Global JusticeXML effort is gaining accep- tance and visibility, and is being used as the basis for the National Information Exchange Model (NIEM), jointly sponsored by the Departments of Justice and Homeland Security. For the safety business area, NCHRP Project 20-64 adopted the NHTSA MMUCC XML schema based on the GJXDM. Future TransXML efforts in the safety arena will need to stay coordinated with related JusticeXML (GJXDM) developments and NIEM developments. • ITS—ITS standards work is ongoing within numerous standards development organizations (SDO). Some of this work is highly relevant to the longer-term objectives of TransXML. A future TransXML steward must determine its appropriate role with respect to ITS XML schema and its relationship to efforts being coordinated by the ITS Joint Program Office. Even though the intent is for TransXML to be an umbrella for development of XML schema for transportation applica- tions, it cannot fully control its world. Several of the logi- cal building blocks for transportation XML schema are and will continue to be developed through outside efforts. This implies that part of TransXML’s role might be to fill gaps that are not being addressed elsewhere, to serve as a “skunk works” for developing schema and applications that then get turned over to appropriate groups for further development and cer- tification, and to serve as a voice of coordination within the transportation sector and provide a liaison function across different schema development efforts. Recognize Distinct Communities Within Transportation The scope of TransXML includes a collection of schema that have distinct (though in some cases overlapping) sets of stakeholder communities. While schema for highway design, bridge design, construction management, and safety may all be relevant to transportation agencies, they are of interest to very different groups/individuals within those agencies, and there are distinct private sector and academic communities across these areas. If and when the scope of TransXML broadens further (as intended), this disparity will increase. Therefore, the nature of TransXML may be more one of a coordinated federation of communities rather than a single cohesive group working towards a specific product. This is an important characteristic to keep in mind in evaluating stewardship options. Marketing and Communication Are Key A key finding of NCHRP 20-64 was the need to aggressively address the marketing and promotional aspects of Trans- XML. The TransXML website presence that was established and maintained in NCHRP 20-64 proved to be reasonably effective in promoting collaboration among willing and inter- ested parties, but recruiting and encouraging the participa- tion of such parties was more difficult than anticipated. A substantial effort (well beyond that which was originally bud- geted) was required to raise awareness of the project to a point at which members of the stakeholder community began to participate in the technical aspects of the project, and the resulting participation was generally neither intensive nor maintained over time. A major reason for this is that there are two different pop- ulations of individuals who need to be addressed in outreach and communications: industry and agency management and IT leaders, and technical staff. The former category of indi- viduals has the broader interests of their agencies at heart, and is most influential in decisions about investments in software and information technology. Communications to these indi- viduals must focus on these overall organizational benefits, and drive the commitment of resources and attention to important technical issues. The latter individuals are the ones who are able to deal with XML schema at a detailed technical level. This is a relatively small population; only a limited sub- set of software and IT professionals in transportation agen- cies (a) are technically qualified to contribute meaningfully to 47

schema development efforts; (b) have a personal or profes- sional interest in the development of data interchange stan- dards; and (c) have the time and resources to commit their efforts to a project such as TransXML. Communications to these groups must have a very different emphasis. Role of AASHTO A final observation is the recognition of the key role of AASHTO in the genesis of TransXML, and the logic of AASHTO continuing to play a key role in this effort. The AASHTOWare Standards and Guidelines Notebook includes an “AASHTOWare XML Implementation and Migration” specification. This specification has the objective of provid- ing a framework to (1) develop XML schema for incorpora- tion into AASHTOWare products and (2) participate in joint development and maintenance of XML schemas with public and private sector partners. It states that XML schema can facilitate data exchange between AASHTOWare products, between AASHTOWare products and third-party products, and between other products utilized by AASHTO member organizations. It also recognizes the ongoing schema devel- opment efforts at LandXML, aecXML and OGC, and states that “AASHTOWare task force members, contractors, and AASHTO staff will participate in these consortiums, where appropriate, and support the development and enhancement of these schemas.” 6.4 Goals and Mission Statement for the TransXML Project Goals of the TransXML Project Based on the above observations, the following goals are proposed for the future TransXML Project. Establish Needs and Demonstrate Value NCHRP 20-64 has established a process for developing consistent, coherent XML schemas in predefined business areas. Several schemas have been developed accordingly, and the process is repeatable for future schemas. However, the key to the long-term success of TransXML is ensuring that the schemas are actually used. The best way to do this is to focus schema development on areas where they are most needed. Interoperability must start with a practical understanding of what data needs to be shared, and how sharing of these data will benefit the transportation community. The criteria stated in Section 4.1 of this report for what constitutes a good can- didate for an XML schema can provide high-level guidance for this. Specific opportunities need to be carefully evaluated to establish a clear vision of where interoperability is most needed and where it could generate the greatest benefits. Broaden the Business Area Focus NCHRP Project 20-64 was designed to focus specifically on four business areas within the much broader surface trans- portation domain. As noted above, some (though not all) of the impetus and support for the project was related to the desire to enhance data interoperability for existing and pro- posed AASHTOWare products, which correspond to the four selected business areas. The project was designed to identify and fill gaps in these business areas in which schema were required but did not yet exist. This proved to be an effective means for concentrating the initial project efforts on well-defined application areas and user communities. At the same time, this approach limited the topical breadth of NCHRP 20-64, and concentrated work in technical areas in which there were a limited number of participating ven- dors. As a result, adoption of the initial XML schemas is expected to be somewhat limited in breadth. While future TransXML efforts should certainly continue to support and enhance the value of AASHTOWare product investment in these four business areas, the TransXML Project should also attempt to 1. Address data exchanges and overlaps with other well- established standardization efforts such as those pursued by FMCSA in the commercial vehicle information systems area, and those pursued in the ITS community. This will help to broaden the scope of TransXML and start the process of building working relationships with these other vital communities. 2. Play a proactive role with new or proposed AASHTOWare efforts, to ensure that data exchange and support for inter- operability are fundamental to the initial releases of new AASHTOWare products. 3. Identify and address other major transportation topic areas which are not covered by AASHTOWare or other existing standardization efforts. Many standards bodies, such as OGC, ISO TC211, and ANSI L1 have been focused on foundation issues, and are only now getting involved in transportation-specific applications on top of those foun- dations. TransXML can provide transportation expertise to support them in these efforts. 4. Promote the importance of data interchange and inter- operability to other agencies that sponsor research in soft- ware and information technology (including, for example, the NCHRP and SHRP II research programs). Formally Embrace Coordination with Other XML Schema Efforts NCHRP Project 20-64 incorporated an effort to identify and evaluate existing XML schema development and other stan- 48

dardization efforts. This was done in part to avoid overlaps with existing work, and in part to identify workable stew- ardship models for TransXML. The experience of NCHRP Project 20-64 and, in particular, the decisions made in that effort to adopt certain technical components of other schemas—or in one case a complete schema—as part of TransXML, underscore the importance of developing a deeper and continuing relationship with these other efforts. The TransXML Project should therefore emphasize coor- dination with other larger-scale, relatively well-established XML Schema standardization efforts in the transportation arena (ITS, commercial vehicles, crash records, etc.) so as to avoid proliferation of incompatible standards. While this sounds straightforward, it represents a substantial practical challenge. Other standards efforts have different goals and objectives and serve different audiences, and often rely on very different technical foundations. For the TransXML Proj- ect to influence existing schema standardization efforts, it will need to build up credibility through meaningful partici- pation. In doing so, the project should be able to leverage its adoption of GML as a unifying framework. Participation in these other efforts requires familiarity with the work per- formed to date and the needs and other characteristics of participants in the relevant standardization community. This, in turn, will require time and financial resources. Balance Schema Development, Advocacy, and Industry Coordination The TransXML Project will need to strike a careful balance between different levels of activity: providing a technical foundation and infrastructure (both administrative and col- laborative) to support schema development activity; address- ing specific data exchanges through schema development; and working with other transportation standards bodies to help establish an overarching architecture for transportation data. The first of these is essential to yield a coherent and coordinated set of work products and to simplify and stream- line schema development efforts; the second is essential to provide a continuous demonstration of successful efforts and value being derived from the project effort; the third is in many respects the “heart of the matter” with respect to the ultimate objectives of the effort. While coordination of existing XML schema development efforts (and, where possible, providing support for these efforts via TransXML standards and infrastructure) is extremely important, it should not dominate the project. The construc- tion and materials business area clearly needs a stewardship body to facilitate development of schemas. The safety busi- ness area also needs a stewardship body to coordinate a wide variety of schema, despite the fact that there are important and relatively well-established schema development efforts (specifically, NHTSA’s crash records schema) already going on in this business area. Beyond Data Exchange; Towards Interoperability NCHRP Project 20-64 emphasized data exchange among applications—defining a common format for data to allow one application to export a data set that can then be imported into a variety of other applications. Current information systems technology is increasingly directed towards service-oriented architectures (SOA), in which a variety of information systems operate in parallel, providing services to each other in an “on call” environment. This approach (often referred to as “web services” in the context of systems that interoperate over the World Wide Web) often leverages XML as a communications medium that allows information systems to operate in tandem, packaging services provided by a number of different systems into applications that meet specific end-user requirements. The TransXML Project should make an effort to promote these potential benefits of XML in addition to the potential data exchange benefits. Examples of potential web services in trans- portation might include searches for facilities (rest areas, tran- sit stations) by location, queries of traffic conditions on a route, validation of standard data sets (e.g., NBI, HPMS), or price lookups for standard pay items. In each of these examples, the web service represents a modular function that consumes and produces a standardized XML data set, and can be called from a variety of web-based applications. TransXML Project Mission Statement The NCHRP 20-64 project team recommends the follow- ing Mission Statement for the TransXML Project: The TransXML Project promotes data exchange and inter- operability of software applications and information systems used by transportation agencies in areas where such interoperability is most needed and will generate the greatest benefits. The Project intends to increase the utility of these systems and enable them to work together more effectively, overcoming existing data communication obstacles, empowering the industry to operate more efficiently and, ultimately, improving transportation in the United States. 6.5 Function and Roles of a TransXML Stewardship Organization The TransXML stewardship organization should provide the following functions: • Continually develop and refine a vision of where inter- operability is most needed and where it can generate the greatest benefits. The steward must not only devise a clear 49

vision of practical, beneficial interoperability, but must then frame that vision in a way that enables stakeholders to per- ceive the potential gain. The greater the need, the more likely it will be that interested parties will participate in the process. This will be an ongoing effort as needs are likely to change over time. • Develop, maintain, and promote a family of XML schemas that target these transportation business areas. The TransXML project can perform these functions in- house using project staff, or oversee work that might be performed through coordinated voluntary efforts or via paid contractors or subcontractors (academic, nonprofit, or commercial). As the business areas addressed by schema become more diverse, it becomes increasingly unlikely that a single organization will hold the required technical expertise, and increasingly likely that contractors or third parties will need to apply their specialized skills and ser- vices. The implication is that the TransXML Project must have the flexibility to arrange for technical work to be performed by others. • Participate in and/or endorse other XML schema and standardization efforts that support its mission, advo- cating on behalf of public sector transportation agencies to encourage those efforts to meet the needs of the Trans- XML community. The TransXML Project should estab- lish and invest in maintaining formal relationships with the following XML schema and standardization efforts: LandXML, OGC’s GML and CAD-GIS efforts, the FGDC Framework Data Content Standard for NSDI, NHTSA crash records schema, the family of ITS standards efforts being coordinated by the ITS Joint Program Office, and the Volpe Center’s efforts to establish XML schema in the commercial vehicle arena on behalf of FMCSA. The Trans- XML Project must also monitor the evolution of new stan- dardization efforts and make decisions about what position to take with respect to these efforts. • Provide industry-wide coordination to ensure coverage across all important segments of the transportation industry. • Establish and promote technical standards to ensure technical compatibility, uniformity, and nonredundancy in the development of XML schema for transportation. These two oversight functions, taken together, are absolutely crucial for TransXML to achieve its mission and fulfill the longer-term goal of creating a library of consistent, com- patible schemas that serve the industry. Gaps in coverage of key transportation business areas will inhibit unified support from agencies and the vendor community; the lack of standards will guarantee confusion and inefficiency as poorly coordinated schema efforts result in conflicts among members of the stakeholder community. These functions must be executed by committed, long-term core TransXML Project staff, and it is a requirement that the project steward have such staff available. • Promote the benefits of TransXML to transportation agen- cies, software and information technology firms, industry research organizations, and the consulting community; champion the adoption and development of TransXML schemas through advocacy, technical assistance, and selective financial support. • Provide communication mechanisms and infrastructure to enable appropriate participation of the various cate- gories of industry representatives in the TransXML schema development process. For the TransXML Project to succeed, the steward will need to aggressively lead out- reach and marketing activities targeted to both the man- agement and technical communities through: information dissemination (including costs of attendance) at relevant industry conferences (e.g., HEEP, AASHTO IS, TRB, ITE, NEMA, ATSIP); preparation and distribution of regular updates on the project through press releases and website updates; proactive electronic communications, including e-mail, newsletters, and participation in relevant news and discussion groups; and preparation and distribution of white papers and other educational materials. 6.6 Criteria for TransXML Stewardship Seven core criteria were identified to evaluate candidate organizations’ capabilities to carry out the functions defined above: 1. Leadership—Established credibility and relationships with the TransXML stakeholder communities, degree of synergy between the organization’s established mission and the objectives of TransXML, impetus and incentives in place for the organization to serve as a champion, ability to build consensus within the stakeholder community(ies); 2. Neutrality—Perceived degree of neutrality across vendors, and perceived degree of commitment to open standards; 3. Stability/Sustainability—Availability of a stable source of funds; likelihood that the organization can sustain itself over a 5- to 10-year period; 4. Agility—Ability to productively and expediently make decisions and move forward with initiatives within a rea- sonable timeframe; 5. Technical Expertise—Availability of in-house staff with technical expertise needed to provide support (training, respond to questions, correct errors) for the schemas devel- oped under this project and for further schema development and application, and/or ability to access these resources; 6. Marketing Capability—Ability to mount an effective mar- keting effort to promote adoption and use of the schemas— 50

even the most sound technical efforts do not flourish with- out a dedicated marketing effort on behalf of the steward organization; and 7. Administrative Infrastructure—Availability of adminis- trative staff and IT support resources that can take on addi- tional incremental responsibilities. 6.7 Recommended Model for TransXML Stewardship Four options were developed for stewardship of TransXML: Option 1: Manage within the AASHTOWare program. This is the status quo “path of least resistance” approach. The premise is that current AASHTOWare subscribers would be willing to have a portion of their license fees go to sup- port incorporation of XML into the AASHTOWare prod- ucts, and for continuing to support the collaborative schema development process launched within NCHRP 20-64. It is also possible that a separate TransXML Task Force within the AASHTOWare umbrella could be established to solicit interest in a TransXML subscription. This would support continued schema development to provide interoperability across non-AASHTOWare applications. Further discussions are required to determine whether an appropriate package of incentives could be provided to encourage a sufficient level of interest (since the premise of TransXML is that it is freely distributed, unlike AASHTOWare product licenses). Option 2: Establish a cooperative agreement including AASHTO, U.S. DOT, and others to support TransXML. This could take the form of a new joint task force (e.g., like the AASHTO/FHWA/TRB Task Force on Asset Manage- ment), or depending on interest, it could be a more ambi- tious new partnership entity with an executive director and a board of directors (e.g., like the National Partnership for Highway Quality, which involves AASHTO, FHWA, APWA, and several industry groups). Member agencies would pro- vide funding and in-kind services. Technical work would be accomplished through contracts and/or volunteer working groups. These working groups could pursue collaborative schema development via established mechanisms provided by OGC, OASIS, and others. Option 3: U.S. DOT-funded competitively awarded multi- year contract with a university research center, nonprofit, or commercial organization (or team) to house TransXML. This option presumes that one or more agencies within U.S. DOT would provide a multiyear commitment of funding for TransXML (analogous to the U.S. DOJ’s commitment to JusticeXML). The contract would be written to include all of the desired functions of TransXML, including stake- holder liaison, schema development, application develop- ment, and technical support functions. Option 4: Establish a new independent nonprofit organi- zation that relies on grants, memberships, and voluntary contributions from the stakeholder community. This is the OGC model. The success of this approach would be very dependent on public agency grants (at least initially), or the development of a business model that provides incentives for membership or revenue-generating products and services. The research team identified a number of factors or crite- ria for evaluating the most appropriate stewardship option: 1. The TransXML mission statement should be most closely aligned with the mission statement of the coordinating body. 2. Long-term, sustainable funding is essential for the success of TransXML. 3. The administrative structure and funding mechanism of the coordinating body must lend itself to the activities described in the TransXML mission statement: stakeholder liaison, schema development, application of development, and technical support. 4. The coordinating body must have credibility and perceived neutrality among the stakeholders. 5. TransXML must be able to reach beyond the traditional boundaries of AASHTOWare applications. 6. TransXML must have broad vendor support. 7. Decisive, central leadership is required. The management structure must be efficient and able to make decisions and achieve consensus quickly. 6.8 Work Plan for the TransXML Project The recommended work plan for the TransXML Project is divided into two phases. The initial phase covers the transi- tion to the new steward organization. The second phase covers the ongoing operation of the project under its new stewardship arrangement. Transition Phase There will inevitably be a gap between the end of NCHRP Project 20-64 and the full transition of TransXML to its future home. In order to ensure a smooth transition and maintain momentum, the researchers recommend that a temporary home be established for the project. Specifically, they recommend that AASHTO take on responsibility for the TransXML project’s transition period. The Subcommittee on Information Systems could take the lead, with participation from the Special Committee on Joint Development (SCOJD). The objectives of this transition period are (1) to maintain momentum for TransXML implementation and (2) to obtain 51

commitment by a unit within U.S. DOT to take on steward- ship of the project. The transition phase should begin as early as possible and end when a commitment for longer-term project stew- ardship has been secured. After a total of 12 months have elapsed, if no workable stewardship arrangement has been identified, then the temporary stewards may conclude that the time is not right for the project to continue in its cur- rent form. The following activities are recommended for the transi- tion phase: 1. Appoint an AASHTO staff person to coordinate the effort. 2. Form a task force for the TransXML transition project. This project task force should include some NCHRP 20-64 panel members to provide continuity. Other desirable members include representatives of state DOTs that have expressed an active interest in TransXML (Nebraska, Idaho, Florida, Minnesota, New York), and representatives from one or more of the following units of U.S. DOT that have an inter- est in transportation data interoperability: the Intelligent Transportation Systems Joint Program Office, the FHWA Office of Asset Management, and the Office of the Chief Information Officer (CIO). 3. Ensure that the members of the task force are familiar with the results of the TransXML project. The NCHRP Project 20-64 Final Report and project briefing can be used as a resource for this. 4. Agree on and implement an action plan for continuity and continued progress during the transition period. This agenda should consider the following elements: • TransXML Website Hosting—Identify an agency or organization willing to take on temporary hosting of the TransXML project website. This will ideally be either AASHTO or a member of the TransXML Transition task force. Website hosting is not likely to require much effort; the goal would be to maintain the project’s presence on the web, including access to the UML models and schema developed as part of the project. The TransXML domain names should be transferred from the NCHRP Project 20-64 contractor to the new host. The new host will be able to obtain all of the website files from the CD- ROM provided to NCHRP at the close of NCHRP Project 20-64. • Conferences—Ensure that the work conducted as part of TransXML is promoted at key conferences, including international HEEP, the Traffic Records Forum, the annual TRB conference, and the annual AASHTO Infor- mation Systems conference. The sample applications developed as part of NCHRP Project 20-64 can be used to communicate what can be done with the new XML schema. • Support for Early Adoption Projects—Early adoption of TransXML schemas by state DOTs is critical. State DOT implementation of the initial TransXML schemas would demonstrate technical commitment by the par- ties most affected by the project. This in turn would present a more persuasive case to potential stewardship organizations and funding agencies of TransXML. One of the NCHRP 20-64 panel member states (Florida) has already begun implementation of the TransXML con- struction and materials schemas. This state DOT should be encouraged to share its experience with peer agencies to establish a base of credibility and support. In addition to offering assistance and encouragement to states tak- ing the initiative to implement TransXML, a pooled fund project (e.g., using State Planning Research (SPR) funds) should be pursued to demonstrate im- plementation of the TransXML schema, and prepare additional web-accessible demonstrations of how these schemas can be used, and what their benefits are. • Liaison with Other Related XML and Data Standards Efforts—Establish relationships with external groups in order to ensure that the work done by TransXML is con- sidered (i.e., not duplicated) by similar efforts, and also to stay abreast of developments which may be incorporated into future TransXML schema. These groups include the Open Geospatial Consortium (OGC); the U.S. DOT ITS Standards Program; the Geotechnical Management System (GMS) effort (see FHWA Pooled Fund Project TPF-5 [111]); and the Department of Justice/Department of Homeland Security National Information Exchange Model effort. Other important stakeholder groups within each business area were listed in Section 5 of this report. 5. Pursue discussions with units within U.S. DOT that could potentially take on stewardship responsibility (primary or shared) for TransXML: the office of the CIO, the ITS Joint Program Office, the Volpe Transportation Center, and the FHWA Office of Asset Management. Use the materials provided below (under Ongoing Operation) to structure these discussions and provide a starting point for identifi- cation of resource requirements. Ongoing Operation Given the proposed mission statement (see Section 6.4) and functions (see Section 6.5) for the TransXML steward- ship organization, the following staff roles and activities are recommended for consideration. They provide the basis for establishing a rough estimate of resource requirements for the effort. It should be kept in mind, however, that there are many possible variations on how this effort can be accom- plished. Other XML efforts have been able to successfully leverage external resources (most notably voluntary labor). Project Lead—Provides overall project direction, advo- cates for continued flow of resources to support the 52

project, manages the contractor, and provides project liaison and communication functions. Project Manager—Manages and coordinates all work in coordination with the Project Lead. With input from the technical architect and the evangelist (see below) develops a recommended work plan on a semiannual basis. This work plan includes an appropriate mix of promotional/educational activities, liaison activities, new schema development work (both to broaden the base of schemas and to extend existing schemas to better serve user needs), and implementation assistance work. Technical Architect—Provides a technical focal point for schema development and liaison with other XML and standards efforts. Works to ensure reuse of existing TransXML components. Continues to extend the base of shared components that span all TransXML schemas. Works with external standards efforts to minimize duplication of effort and to foster consistency in defini- tion of data concepts. Identifies externally developed schema for incorporation into the TransXML umbrella. Manages modifications to existing schema with consid- eration of backward compatibility issues. Coordinates with the Open Geospatial Consortium on GML issues and evolution. Provides technical assistance to Trans- XML schema developers to ensure consistency and compatibility across new schema efforts. Maintains a consolidated set of UML models for TransXML schema. Programmer/Analyst—Supports the technical architect in maintenance and development of the TransXML code base, consisting of UML models, schema (.XSD), sample instance files (.XML), and sample applications. Develops utilities as needed for XML validation and sample appli- cations. Maintains the TransXML website. Evangelist—Serves as primary liaison with various stake- holder communities, including AASHTO committees, state DOTs, MPOs, and software vendors. Manages stakeholder forums on the TransXML website. Develops and delivers conference presentations on TransXML schema, applications, and value added. Identifies oppor- tunities for collaboration with external schema devel- opment efforts. Promotes and provides assistance for TransXML implementation. Develops and disseminates case studies of TransXML implementation. Identifies needs for new schema or schema extensions based on stakeholder input. Administrative Assistant—Provides clerical and produc- tion support to the project. Table 4 presents a rough estimate for the minimum level of funding necessary to support the above positions. This esti- mate does not include the Project Manager position, and it assumes that all of the other positions are full-time and pro- vided by a contractor. An additional $150,000 is added to fund a grant program that could be administered by the Proj- ect Manager in coordination with the Contractor. The idea behind this grant program would be to provide seed funds for projects to develop additional sample applications, and import/ export routines for existing systems in order to help imple- ment existing TransXML schema. While it is certainly possible to define a “minimalist” approach for TransXML that would cost less, it is the research team’s view that to credibly address the mission statement that has been defined above, there needs to be a critical mass of visibility and effort and the resources to support that. A scaled-down version of a continued TransXML project would need to operate under a more modest mission state- ment that emphasized either maintenance and support for the existing schemas or a single coordinator/architect posi- tion combined with matching or grant funds to continue schema development in specific areas. 53 Budget Item Cost Estimate (Annual) TransXML Project Manager $200,000 TransXML Architect $200,000 Evangelist $120,000 $100,000Programmer/Analyst Administrative Assistant $50,000 Direct Costs (including travel for 5-10 conferences per year) $50,000 Demonstration Project Funding $150,000 Total $870,000 Table 4. TransXML contract budget estimate.