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.
13 : Introduction 1.1 About This Research Project This project focuses on a key building block for enabling demand responsive transportation services in the U.S. to more fully, and easily, participate in the era of âNew Mobilityâ. The primary product of this effort is a comprehensive data specification for the ordering and scheduling of trips and vehicles in demand responsive transportation servicesâthe transactions that are at the heart of providing these types of services. Transactional data specifications include the mechanisms for the software systems of various service providers to routinely exchange such information so that inter-operability among services becomes feasible. This report (1) presents new transactional data specifications for demand responsive transportation, (2) makes a case for why key stakeholders in the public sectorâthose that fund and provide demand responsive servicesâshould adopt and build out these specifications, and (3) provides some tools to help them do so. Once implemented, the proposed transactional data specifications will improve the availability, cost-effectiveness, and quality of demand responsive transportation services. The primary beneficiaries include: â¢ Customers will benefit because transactional data specifications can facilitate increased availability of demand responsive services. â¢ Demand responsive service providers will benefit because they can better utilize their vehicles, serving more customers at a lower cost per trip, and more seamlessly inter-operate with public transportation organizations and others who fund these services. â¢ Publicly supported transportation organizations will benefit from being able to improve the cost-effectiveness of DRT services as it becomes possible to use multiple transportation providers for a single service program, while also fostering competition among them. â¢ Government transportation funding programs will benefit by more efficiently and effectively using public resources to fund transportation services and by improving mobility services to local communities. Experience in Denmark over the past 10 years demonstrates that improvements can occur when transactional data specifications become integral to demand responsive transportation. Making this a reality in the U.S. would represent an important building block for more effective use of demand responsive transportation for public purposes. 1.2 What Is Demand Responsive Transportation? Demand Responsive Transportation (DRT) covers a wide range of on-demand services. For this report, DRT broadly refers to transportation services in which vehicles only operate in response to ride requests, and in which vehicles are routed in such a way to transport passengers from their origin to their destination. In contrast to fixed route transit, in which the passenger must access the service, in DRT the service mostly or completely tailored to the passengerâs specific trip. Rider trip requests are scheduled through an automated or manual system. Vehicles are scheduled and routed in accordance with the specific elements of the demand for service; the scheduling system considers origin, destination, desired pickup time and/or desired arrival time, vehicle requirements, and other trip requirements.
14 Using this broad definition as applied to both public and private transportation services, DRT includes the following: â¢ Dial-a-ride services, the term historically used to refer to public transit shared ride DRT services for the general public, or similar services geared towards seniors. â¢ ADA complementary paratransit services, shared ride DRT required by the Americans with Disability Act (ADA); restricted to individuals who are unable to use available fixed route services because of some type of disability condition. â¢ On-Demand/Flex/Micro-Transit services (all these terms refer to essentially the same thing), contemporary versions of shared ride DRT service using more advanced technology and potentially using service concepts such as virtual stops or dynamic routes, provided for public transportation purposes for community circulation or first mile/last mile access to rail transit and express bus services. â¢ Ride hailing services, for-hire on-demand transportation services engaged by a smartphone app, such as those of Uber, Lyft, Via and other transportation network companies (TNCs), most commonly using vehicles owned by the drivers who connect to the service network via a driver app. These services may be of a shared ride nature, e.g., Uber Pool, Lyft Shared, Via Van, as well as for individually-directed taxi-like trips. â¢ Taxi services, which is for-hire transportation providing on-demand rides for any paying passenger using vehicles that are clearly identified as being taxis. Together, these demand responsive services provide transportation to a wide variety of passengers, with or without mobility impairments, in both urban and rural communities. Figure 1-1 shows two of the many types of vehicles that are used for DRT services. We recognize that historically the âDRTâ acronym has referred to public transportation types of services that are shared ride in nature, hence excluding general for-hire transportation in which the vehicle is under the exclusive control of the rider. Taxis or similar services provided by ride hailing services (i.e., Transportation Network Companies such as Uber and Lyft) are typically in this latter category, but have also been used for public transportation purposes in certain situations. For the purposes of this report, DRT is defined broadly, to include all forms of demand responsive transportation in the transactional data specification. As emphasized above, DRT services for public transportation purposes typically involve unrelated parties sharing a vehicle which is under the control of the system, not each individual rider. Figure 1-1: Examples of Vehicles Used for DRT Service
15 Examples include services for the general publicâoften referred to as âDial-a-Rideââthat exist in hundreds of communities throughout the U.S., as well as services operated by publicly-funded human service organizations, ADA paratransit services, and many airport shuttle services. In this report DRT services that feature mandatory sharing of the vehicle by un-related parties are referred to as shared ride DRT. 1.3 What Is Transactional Data for DRT? Transactional data are the data created for each ride occurring in a DRT service spanning a âtrip lifecycleâ that begins with a trip booking request and ends when a customer is delivered and the financial settlement information needed for the trip has been exchanged among the customer, the service provider, and any third party funding entity. Transactional data contain all pertinent trip details in a reservations and scheduling system, such as origin and destination location and time of the requested pickup or delivery. These data are then used to assign the appropriate vehicle and service for a trip, be it with or without wheelchair access, special assistance for passengers with health issues, or other special needs specific to a trip. Figure 1-2 provides a definition. The specific elements included in DRT transactional data are discussed in detail later in this report. 1.4 The Technology and Market Context of Transactional Data Specifications Technology platforms have become the centerpiece of much of what is often referred to as âNew Mobilityâ services. New Mobility services include ride hailing, bike sharing, car sharing, electric scooters, and other smart phone enabled travel mode. These service platforms are also able to be accessed via Mobility-as-a-Service (MaaS) applications providing an integrated view of all urban transportation options, including multi-modal trips and certain transactional and payment capabilities. Platforms are now the gateway to most mobility servicesâof whatever typeâthat are available on-demand. This essential connection between technology and New Mobility services provides the background for the direction of this study. The importance of a transactional data specification is integrally connected to the need for inter-operability among multiple technology systems; connected digital platforms promise more effective approaches to providing DRT. Figure 1-3 shows how DRT transactional data specifications fit into the larger data framework that is developing for public transportation services. This framework began with the development (by Google) of the General Transit Feed Specification (GTFS) and is moving rapidly in the direction of MaaS platforms that encompass all forms of available mobility services and can include open Transactional data includes information necessary for transportation service providers (e.g., operators, agencies) to book and complete a DRT trip, such as: - Origin - Destination - Requested time (pickup / arrival) - Passenger attributes (e.g., wheelchair) - Actual pickup time - Actual arrival time - Trip fare (to passenger) - Trip cost (to provider) Figure 1-2: Definition of Transactional Data
16 source trip planning tools such as Open Trip Planner that promise to make basic MaaS functionality widely available. Figure 1-3: DRT Transactional Specification in Transit Data Context As Figure 1-3 illustrates, transactional data specifications are poised to play a key role in a public transportation future in which demand responsive services are one of the important elements of local mobility. In particular, they make it simple for DRT services to be included in MaaS systems, not merely from the perspective that a service is available, but also to book rides on the service and pay for those trips. This is essential if such services are to realize their potential for first mile/last mile access to high capacity rail and bus transit and for community circulation in environments in which fixed route bus service is ineffective and costly. Transactional data specifications in conjunction with technology platforms also offer the possibility of more effective resource utilization for DRT services. Traditionally, such servicesâ whether in the public or private sectorâhave been managed by a single software system in a closed environment that is incompatible with the software systems of other transportation service organizers or service providers. Service integration either vertically or horizontally could occur Discovery Data Specifications General Transit Feed Specification (GTFS) GTFS describes fixed-route services. GTFS-RT describes real time location and ETA GTFS-Flex describes DRT services. Trip Planning Creates an itinerary from origin to destination. May be multimodal -- user presented with options and selects a mode. May be intermodal with GTFS-Flex. Transactional Data Specifications Describes a DRT trip with data messages and data elements. Validation tool provided. DRT Transactions Trip data can be exchanged among scheduling software systems or through a data hub. Financial Systems Fares and fare payment systems. DRT fees for service provision. DRT fee billing/payment systems Source of funding considerations. DRT Scheduling Booking, scheduling, dispatching. Multiple service providers Multiple scheduling systems Mobility as a Service (MaaS) A comprehensive technology platform that enables users to discover, schedule, and pay for trips across multiple modes.
17 only if all participants used the same software or if bespoke data specifications were developed to enable inter-operability, which has rarely occurred. The result: demand responsive transportation is an area in which coordination across suppliers/service organizers in ways that improves service and efficiency is virtually non-existent in the U.S. In order for technology platforms to make possible more coordinated, integrative approaches to service organization and delivery for demand responsive transportation services, data inter- operability across software systems is essential. This research project has considered the methods of achieving inter-operability and identified the development of transactional data specifications as the preferred solution to achieving software/data inter-operability and facilitating service coordination across demand responsive transportation systems. Such data specifications are essential to a future in which these services can readily involve multiple service sponsors, funding sources, and transportation providers inter-operating viaâor acrossâtechnology platforms. 1.5 Examples of Transactional Data Specifications in Transportation Transactional data specifications are used in many market contexts. The combination of data specifications and technology platforms has fundamentally changed other transportation markets; two highly relevant examples are the online travel agencies and demand responsive transportation for public transportation purposes in Denmark. Online Travel Agencies Online travel agencies (OTAs) like Orbitz and Expedia revolutionized how consumers select a travel itinerary and purchase airline tickets and other travel services. The OTA platforms became feasible because of data technology developments circa 2000 that made it possible to inter- operateâusing standardized data flowsâwith the technology systems used by the airlines and the global distribution systems (the latter manage transactions for many airline ticket bookings). Standardized data made price/service comparisons among airlines seamless. Consumersâ platform usersâcould view and compare information about services and prices on multiple airlines without searching among multiple airline web sites and then select and book their preferred flight and pay for their tickets, all using the OTAs. Over time, the scope of what these platforms can accomplish for consumers has expanded (seat assignments, baggage fees, etc.) as all parties (airlines, global distribution systems, OTAs) agreed on additional data specifications, a process that continues to evolve. The OTAs are examples of consumer payment-based platform-enabled transportation services. They represent a specific type of an e-commerce service targeted at individual consumersâthe entire process is handled through private sector mechanisms. In contrast, FlexDanmark is an example of platform-enabled transportation services constructed on a public sector foundation. The FlexDanmark organizationâitself a government-chartered enterpriseâhas developed the worldâs largest demand responsive transportation system on a foundation whose essential elements are third-party funding sources from the public sector and a comprehensive technology platform.
18 FlexDanmark: Denmarkâs Nationwide DRT FlexDanmark is the platform for DRT delivery throughout Denmark. Organized into Denmarkâs six large regional public transportation service districts, DRT services are available to the general public and other target populations, with a large health-care related transportation component. Overall ridership is about 18,000 trips per weekday. Funding is provided by over 500 public sector (or quasi-public sector) entities including municipalities, human service organizations, hospitals and other health care organizations, and school districts. Service providers include over 500 private transportation contractorsâtaxi companies, school bus contractors, medical van providers, and others, all of whom must meet certain performance standards. The FlexDanmark platform includes comprehensive functionality for trip bookingâvia both agents in call centers and direct on-line access for many agencies, trip scheduling, assignment of transportation service providers and vehicles, vehicle tracking, and financial transactions for funding sources and service providers. The FlexDanmark central platform inter-operates with the scheduling/dispatching systems of all of the transportation service providers using standardized data protocols and flows, based on a Scandinavian transactional data specification scheme (the SUTI standard) developed specifically for demand responsive transportation. The SUTI specificationâto which adherence is mandatory for all transportation service providers (i.e., their software systems must be able to exchange data messages with the FlexDanmark platform using SUTI âlanguageâ)âis the foundation for the inter- operability that enables multiple providers and/or multiple service purchasers (e.g., hospitals, municipalities) to be able to âspeakâ with the FlexDanmark platformâand hence indirectly with each other. This world class DRT system depends fundamentally on a comprehensive transactional data specification. 1.6 Who Are the Stakeholders for DRT Data Specifications? The DRT industry is comprised of a variety of organizations with different roles. This includes public sector organizationsâwhose roles in DRT can include organizing/sponsoring services, funding the service, and/or managing service as well as directly operating the service, as well as private sector entities that may operate DRT services or provide technology of various types. Adoption of the recommended transactional data specification will require buy-in and action from stakeholders. The primary stakeholders for DRT data specifications, and the most important target audience for this report, are the following types of organizations and actors: â¢ Public transportation agencies: In the United States, public transportation agencies (including municipalities and counties when they play this role) typically fund and manage DRT services such as dial-a-ride, ADA paratransit, and the emerging on- demand/flex/micro-transit services. A public transit agency may operate the services directly, or it may contract a private company to operate these services; the latter is more common. â¢ Human service agencies: Human service agencies, typically private non-profit organizations, may also directly provide DRT services. Often these services are oriented to the elderly, persons with disabilities and/or mobility limitations, or other human service clients.
19 â¢ Federal Transit Administration: While FTA provides policy leadership and funding programs for public transportation, it has not to date perceived its mandate to extend to providing regulations for data standards for operation of transportation programs and services. Policy makers at FTA clearly understand the desirability of data specifications for all aspects of public transportation where data interchanges can improve outcomes. â¢ State DOTs: As significant funders of public transportation in many states, particularly for small cities and rural/semi-rural areas where DRT services are more likely to be found, state DOTs have reasons for a policy interest in the adoption of data specifications. But like FTA, this is not an area where virtually any state DOTs have been involved to date. â¢ Other public funders of transportation service: A significant amount of DRT service is funded through health care or human service transportation programs. This includes Older Americans Act services, Center for Medicare and Medicaid Services, and a variety of other public sector funded programs. The organizations in this category do not directly operate DRT for their clients, but fund the services that are provided by others, typically private transportation contractors, often including taxi companies. â¢ Technology providers: Private companies that provide specific technology (typically software) systems or services in the DRT industry. This includes: software systems that are used to schedule and manage DRT trips; larger software platforms that include trip planning and fare payment capabilities and also provide integrated mechanisms to engage DRT services for consumers; hardware-based technology with embedded software such as mobile data terminals and handheld devices. Some of these companies have literally hundreds of customers, and others have a handful. With the advent of a new generation of on-demand services, in conjunction with developments in technology, there has been a significant expansion of the number of companies in this category. â¢ Private transportation operators: A variety of private companies provide DRT services to publicly funded agencies or to businesses. Some operate under contracts in which the vehicles, DRT software, and other technology are provided by the service organizer. Others are required to provide vehicles and technology, along with drivers, as part of the contract. Depending on the structure of the contract, these companies may provide their own vehicles, drivers and operational staff as well as specialized software for DRT and/or ADA paratransit and other technology (e.g., mobile or tablet computers in the vehicle). Private operators include national companies (e.g., First Transit, TransDev, MV Transportation) as well as regional and local companies. They also include taxi companies in many settings. â¢ Taxi operators: Taxi operators occupy a special position, as they derive the majority of their revenues from private for-hire servicesâas with TNCsâyet have been used for public sector-funded demand responsive transportation services for many decades in many cities around the country. Now facing an existential threat from the TNCs, the taxi sector has been a partner to the public transportation sector that has certain advantages compared to TNCs and whose preservation is considered important by many involved in DRT.
20 â¢ Transportation Network Companies (TNCs): Private providers of ride-hailing (or ride- sourcing) services. They typically have a technology platform that manages the entire service, accepting trip requests from customers initiated via a smartphone application, and then assigning rides to specific vehicles. This includes companies such as Uber and Lyft for taxi-like service (which includes shared taxi services such as Uber Pool and Lyft Shared) and Via for shared-ride van services. It bears emphasizing that the TNCs are larger economic entities than any of the other organizations in the DRT industry. â¢ Researchers and Consultants: Academic researchers and consultants who work on projects in the DRT industry may also find this report to be relevant to their work, particularly the community of data specialists in the public transportation and on-demand services sectors. The latter recognize the importance of data specifications in all forms of urban mobility. 1.7 Benefits and Challenges of Implementing Specifications Benefits The benefits of transactional data specifications vary according to the interest of the stakeholder. For public transportation agencies and publicly funded entities that operate or fund DRT services, the implementation and use of transactional data standards would help them to better achieve three important policy goals. 1. Improve Coordination. Data specifications for DRT services can improve productivity and effectiveness by better enabling existing DRT providers to share riders and group passengers traveling along similar paths and reduce the number of empty seats on return trips. For difficult to serve lengthy regional or rural trips, it will allow providers to schedule vehicle trips that combine a variety of passengers so the cost per passenger is reduced. 2. Create Opportunities for Improved Cost-Effectiveness of DRT Services. Many DRT services are costly and strain the resources of the organizations that fund them. There are multiple reasons for this, but transactional data specifications that enable multiple DRT service providersâand particularly those not previously involved but able to provide non-dedicated vehiclesâto be engaged so that the supply of service can be more closely tailored to demand patterns creates opportunities for more cost-effective DRT. FlexDanmark has been particularly effective in taking advantage of these non-dedicated vehicle providers, and studies in Denmark indicate that it is able to deliver service for significantly less cost per passenger trip than the DRT services that existed prior to its introduction. 3. Strengthen Private Sector Involvement. Digital interaction capabilities that encompass both the source of DRT trips (trip booking systems) and the software systems of DRT providers-- which require a data specification that spans these domains--will enable transportation and human service agencies to more easily use a variety of DRT providers, many of which are in the private sector. A few agencies have developed efficient approaches to serve multiple types of trips with diverse purposes and destinations by creating fleets from multiple sources,
21 including contracting some service to taxi companies and other private providers1. A uniform approach for transactional data would make it much easier for a multitude of small providers to participate in the delivery of DRT services. The expected benefits are similar to what FlexDanmark has experienced, namely lower costs and a more robust network of service providers. Challenges There are at least three key challenges that must be overcome for the benefits of transactional data specifications for DRT to be realized. â¢ Widespread adoption takes time. It takes time to develop, implement, and institutionalize the use of specifications. While GTFS is an example of the effective use of a specification, it is important to remember that it took well over a decade for widespread adoption. Early adopters do enjoy some benefits, but it is not until a significant number of entities adopt a standard that the benefits multiply. â¢ Change is difficult. Change itself is often the most formidable challenge. Adopting a new way of doing business requires change among public agencies, DRT service providers, and technology companies. This will require adaptation, learning a new âlanguageâ and establishing new business rules and quality control mechanisms. â¢ Lack of leadership or champion. A fundamental challenge to the adoption of the recommended transactional data specifications by the DRT industry is that there is no current group or entity leading this effort. To date, no stakeholder has demonstrated sufficient interest or willingness to take a leadership role in promoting transactional data specifications for DRT. Without a leader it will be difficult to carry such an initiative far enough to realize the complete benefits. A champion would inform others about the benefits of adoption of data specifications, provide technical materials (such as language for procurement documents), and oversee a process to develop and maintain the integrity of the specifications. This latter process is important so developers can depend on the specifications for use in creating a technology platform. 1.8 Strategies for Successful Adoption of Data Specifications Existing Systems While establishing a specification-based digital infrastructure for demand responsive transportation in the U.S. will be challenging, successful models exist for achieving this. As explained in Chapter 3, several European countries have adopted transactional data specifications developed initially in Sweden (SUTI standards), and there is now a process that spans multiple 1 A brokerage model is often cited as desirable, with a single agency controlling many different providers using a single scheduling system. The ACCESS service in Pittsburgh and throughout Allegheny County is an example of this, serving a population of 1.2 million in an area of 745 square miles. They provide services for over 140 agencies using six providers and over 300 vehicles, so each providerâs fleet is fairly large. Contrast this with FlexDanmark which serves a population of 6 million in a much larger area (875,500 square miles) and uses 500 providers, many of which are small âmom and popâ providers. Larger forms of the broker model are feasible with the right underpinnings.
22 countries by which those data standards are governed and can evolve. But while the technical approach to the SUTI data specifications provided an excellent framework for this research project, the way in which those specifications have been adopted and subsequently governed cannot be simply transferred to the U.S. context in view of the more authoritative role of the central government in Scandinavian countries. The successful systems from Sweden and Denmark do provide important guidance to the U.S. situation, the key lesson being that it is the governmental (or quasi-governmental) organizations that fund local transportation services who are the entities which must act decisively to initiate the process of specification adoption. Specification implementation will only occur when such entities insist upon it as a condition for doing business with them or their service provider agents. For transactional data specifications to be widely adopted, it is desirable that one or more organizations that represent public sector funding sources assume a leadership role in such an initiative. For assuring the specification can continue to be developed while maintaining the integrity necessary for use in technology platforms, such leadership and a process of governance will be necessary. Support Materials The research team developed materials to assist public agencies and other funding sources in understanding the transactional data specifications developed in this project so that they can advocate for, and potentially lead, a process that could result in industry-wide adoption of these (or comparable) specifications. The research report includes information that will facilitate the adoption and use of transactional data specifications for DRT including: â¢ Materials to market the specifications, specifically a document that makes the business case for the proposed specifications; â¢ Stand-alone technical materials, including a software tool that can validate data flows for consistency with the proposed specifications, that can be used to develop specification- compliant data exchanges; â¢ Requirements that can be included in Requests for Proposals that can be used by organizations to stipulate that DRT services that they contract for or fund and scheduling software they purchase must be compliant with the proposed transactional data specifications for DRT. For the interested few to use these materials could result in a âbottoms upâ approach to specification adoption, one that is relatively novel and could take a few years to make an impact across the entire industry. However, if even a relatively small number of organizations or states, adopted this approach to technology procurement it might lead to a much broader movement within a year or two and stimulate an industry-wide adoption of transactional data specifications. The experience from Europe with the SUTI standards indicates that DRT transactional data specifications can be developed and adopted by those who fund these services. To support continued development of the specifications and maintain the integrity necessary to develop the technology platforms that will allow entities to realize the full benefits of having specifications, a means of governance will be needed.
23 The purpose of this report is to provide those who wish to engage in this process with the rationale, knowledge, and practical tools to adopt and promote the widespread use of transactional data standards for DRT in the U.S. 1.9 How This Report Is Organized This report consists of five chapters and eight appendices. The first and fifth chapters are oriented to a broad audience, covering all stakeholders who have an interest in the development and adoption of transactional data standards for DRT. In Chapters 2, 3, and 4 the report focuses on the process of developing specifications that are functional for DRT providers and practical for technology vendors. These three chapters provide information on what was considered in developing the specifications and the result of the research, a proposed specification. Chapter 5 returns to a broader discussion of implementation. The appendices provide technical documentation of the specification and tools for implementation. Chapter 1: Introduction This chapter provides an overview of demand responsive transportation and of transactional data. It identifies the reportâs target audience. It also previews the rest of the report. Chapter 2: Considerations in Developing the DRT Transactional Data Specification This chapter discusses the key factors that were considered to develop the proposed DRT transactional data specification. These factors include core design principles such as simplicity and flexibility, market considerations, and the specific functional requirements for a DRT transactional data specification. Different technical models for implementing a DRT transactional data flow are described and a preferred model is presented. Chapter 3: Examples of Transportation Data Specifications This chapter presents five examples of common data formats in the transportation industry, beginning with an example from the airline industry. The second and third examples pertain to the General Transit Feed Specification (GTFS) that is commonly used to provide information about fixed route transit services and a new extension for flexible transit services. The last two examplesâone from the Denver region and another from Scandinaviaâare most relevant to this project and present examples specific to DRT transactional data. Chapter 4: Summary of the Specification This chapter presents an overview of the proposed DRT transactional data specification. Important technical elements, such as the data communication approach and types of data elements, are explained. Additional technical details can be found in Appendices 4 and 5, which contain the full documentation for the proposed specification. Chapter 5: Conclusions and Future Considerations The final chapter presents a short summary and key conclusions from this research project. Notable future considerations for implementation, such as governance for the specification moving forward, are also discussed.
24 Appendix 1: Members of the Industry Advisory Panel This appendix contains a list of the industry experts on the advisory group that participated in some or all of the industry Advisory Panel meetings. Appendix 2: Engaging Industry Experts In this project, a group of industry experts was engaged to advise the development process. This appendix summarizes the research teamâs interactions with the industry experts throughout the duration of this project. The industry Advisory Panel participants took part in regular virtual meetings (calls) to provide input on the specification implementation. In the early stages of the project, team members conducted semi-structured telephone interviews with the members of this group to document their views of the benefits, challenges, and best approaches to developing a DRT transactional data specification. This appendix contains the protocol for those interviews. Appendix 3: Industry Advisory Panel Final Meeting Presentation This appendix contains the presentation provided to industry Advisory Panel members on the final meeting of the project with this group. It summarizes the project and outlines important future considerations, such as governance issues. Appendix 4: Detailed Specification Description This appendix contains the full documentation for the proposed DRT transactional data specification. This appendix is intended for audiences with background in software development and/or information technology. Appendix 5: XML Listing of Specification This appendix contains the XML listing of the specification. Appendix 6: Validation Tool This appendix describes the tool that was created during this project to validate the specification. The tool is publicly available on a website whose URL is published in the appendix. Appendix 7: Marketing Document This appendix contains a short (one page) marketing document that can be given to managers at transit agencies and/or other DRT service providers. It briefly explains (1) what a DRT data specification is; and (2) why DRT providers should adopt it. It is written in a non-technical manner. Appendix 8: Request for Proposals (RFP) Language This appendix presents two sets of text that could be used in a request for proposal (RFP) for paratransit scheduling software that would adhere to the proposed DRT transactional data specification. The first could be used by a transit agency and/or other DRT service providers in a request for proposal for procuring software; the second could be used in an RFP to assure that DRT services that are procured operate with technology that is compliant with the specifications.