Principios rectores
Para preservar la visión original de la especificación GTFS Realtime, se han establecido una serie de principios rectores que se deben tener en cuenta al extender la especificación:
Producir y utilizar feeds en tiempo real debe ser un proceso eficiente.
La información en tiempo real es una transmisión de datos continua y dinámica que necesariamente requiere un procesamiento eficiente. Elegimos búferes de protocolo como base de la especificación debido a que ofrecen un buen intercambio en términos de facilidad de uso para los desarrolladores y en términos de eficiencia para la transmisión de datos. A diferencia de la especificación GTFS, no creemos que muchas empresas vayan a editar los feeds GTFS Realtime de forma manual. La elección de búferes de protocolo refleja la conclusión de que la mayoría de los feeds GTFS Realtime se producirá y se utilizará de manera programática.
La especificación hace referencia a la información de los pasajeros.
Al igual que la especificación GTFS, GTFS Realtime se ocupa, principalmente, de la información de los pasajeros. Es decir, la especificación debe incluir, ante todo, información que pueda facilitar herramientas de gran utilidad para los pasajeros. Existe una gran cantidad de información orientada a las operaciones que las empresas de transporte público pueden querer transmitir de manera interna entre los sistemas. La especificación GTFS Realtime no está diseñada para ese fin; además, es posible que haya otros estándares de datos orientados a las operaciones que puedan ser más adecuados.
Los cambios en la especificación deben ser retrocompatibles.
Al agregar funciones a la especificación, tenemos que evitar realizar cambios que invaliden los feeds existentes. No debemos generar más trabajo para los publicadores de feeds existentes hasta que sean ellos quienes deseen agregar funciones a sus feeds. Además, siempre que sea posible, los analizadores existentes deberían poder continuar leyendo las partes más antiguas de los feeds más nuevos. Las convenciones para extender los búferes de protocolo impondrán la retrocompatibilidad hasta un cierto punto. Sin embargo, debemos evitar hacer cambios semánticos en los campos existentes que también puedan arruinar la retrocompatibilidad.
No se recomiendan las funciones especulativas.
Cada función nueva agrega complejidad a la creación y la lectura de los feeds. Por lo tanto, debemos ser cuidadosos de agregar solo funciones que sabemos que serán útiles. Idealmente, todas las propuestas se probarán mediante la generación de datos para un sistema de transporte público real que utilice la función nueva y a través de la escritura de software que permita leerlo y mostrarlo.
Usaremos extensiones, que se describen en la siguiente sección, para admitir funciones nuevas. Los productores y usuarios de GTFS Realtime primero pueden probar una función nueva en el espacio de la extensión. Cuando la función esté lista para la adopción oficial, la agregaremos a la protodefinición oficial de GTFS Realtime.