Allow multiple entity types in single feed.

gtfs-realtime/spec/en/README.md

@@ -5,24 +5,24 @@ The specification was designed through a partnership of the initial [Live Transi
 ## How do I start?
 
 1.  Continue reading the overview below.
-2.  Decide which [feed types](feed-types.md) you will be providing.
+2.  Decide which [feed entities](feed-entities.md) you will be providing.
 3.  Take a look at [example feeds](examples/).
 4.  Create your own feeds using the [reference](reference.md).
 5.  Publish your feed.
 
-## Overview of GTFS Realtime feed types
+## Overview of GTFS Realtime feeds
 
 The specification currently supports the following types of information:
 
 *   **Trip updates** - delays, cancellations, changed routes
 *   **Service alerts** - stop moved, unforeseen events affecting a station, route or the entire network
 *   **Vehicle positions** - information about the vehicles including location and congestion level
 
-Updates of each type are provided in a separate feed. Feeds are served via HTTP and updated frequently. The file itself is a regular binary file, so any type of webserver can host and serve the file (other transfer protocols might be used as well). Alternatively, web application servers could also be used which as a response to a valid HTTP GET request will return the feed. There are no constraints on how frequently nor on the exact method of how the feed should be updated or retrieved.
+A feed may, although not required to, combine entities of different types. Feeds are served via HTTP and updated frequently. The file itself is a regular binary file, so any type of webserver can host and serve the file (other transfer protocols might be used as well). Alternatively, web application servers could also be used which as a response to a valid HTTP GET request will return the feed. There are no constraints on how frequently nor on the exact method of how the feed should be updated or retrieved.
 
 Because GTFS Realtime allows you to present the _actual_ status of your fleet, the feed needs to be updated regularly - preferably whenever new data comes in from your Automatic Vehicle Location system.
 
-[More about Feed types...](feed-types.md)
+[More about feed entities...](feed-entities.md)
 
 ## Data format
 

gtfs-realtime/spec/en/feed-types.md → gtfs-realtime/spec/en/feed-entities.md

@@ -1,8 +1,6 @@
-GTFS Realtime supports three distinct types of realtime data. Even though the
-[gtfs-realtime.proto](../../proto/gtfs-realtime.proto) syntax allows
-multiple entity types to be mixed for a feed, only one type of entity can be
-used in a particular feed. Summaries are given below, with full documentation
-given in the relevant section.
+GTFS Realtime supports three distinct types of realtime data, that can be
+combined witin a single realtime feed. Summaries are given below, with full
+documentation given in the relevant section.
 
 ## Trip Updates
 

gtfs-realtime/spec/en/reference.md

@@ -46,7 +46,6 @@ The contents of a feed message. Each message in the stream is obtained as a resp
 A feed depends on some external configuration:
 
 *   The corresponding GTFS feed.
-*   Feed application (updates, positions or alerts). A feed should contain only items of the appropriate applications; all the other entities will be ignored.
 *   Polling frequency, controlled by min_update_delay, max_update_delay.
 
 #### Fields
@@ -73,7 +72,7 @@ Metadata about a feed, included in feed messages.
 Determines whether the current fetch is incremental.
 
 *   **FULL_DATASET**: this feed update will overwrite all preceding realtime information for the feed. Thus this update is expected to provide a full snapshot of all known realtime information.
-*   **DIFFERENTIAL**: currently, this mode is **unsupported** and behavior is **unspecified** for feeds that use this mode. There are discussions on the [GTFS Realtime mailing-list](http://groups.google.com/group/gtfs-realtime) around fully specifying the behavior of DIFFERENTIAL mode and the documentation will be updated when those discussions are finalized.
+*   **DIFFERENTIAL**: currently, this mode is **unsupported** and behavior is **unspecified** for feeds that use this mode. There are discussions on the [GTFS Realtime mailing list](http://groups.google.com/group/gtfs-realtime) around fully specifying the behavior of DIFFERENTIAL mode and the documentation will be updated when those discussions are finalized.
 
 #### Values
 
@@ -98,7 +97,7 @@ A definition (or update) of an entity in the transit feed. If the entity is not
 
 ## _message_ TripUpdate
 
-Real-time update on the progress of a vehicle along a trip. Please also refer to the general discussion of the [trip updates feed type](trip-updates.md).
+Realtime update on the progress of a vehicle along a trip. Please also refer to the general discussion of the [trip updates entities](trip-updates.md).
 
 Depending on the value of ScheduleRelationship, a TripUpdate can specify:
 
@@ -139,7 +138,7 @@ Uncertainty applies equally to both time and delay. The uncertainty roughly spec
 
 ## _message_ StopTimeUpdate
 
-Realtime update for arrival and/or departure events for a given stop on a trip. Please also refer to the general discussion of stop time updates in the [TripDescriptor](#TripDescriptor) and [trip updates feed type](trip-updates.md) documentation.
+Realtime update for arrival and/or departure events for a given stop on a trip. Please also refer to the general discussion of stop time updates in the [TripDescriptor](#TripDescriptor) and [trip updates entities](trip-updates.md) documentation.
 
 Updates can be supplied for both past and future events. The producer is allowed, although not required, to drop past events.
 The update is linked to a specific stop either through stop_sequence or stop_id, so one of these fields must necessarily be set.
@@ -212,7 +211,7 @@ Congestion level that is affecting this vehicle.
 
 The degree of passenger occupancy for the vehicle.
 
-**Caution:** this field is still**experimental**, and subject to change. It may be formally adopted in the future.
+**Caution:** this field is still **experimental**, and subject to change. It may be formally adopted in the future.
 
 #### _Values_