Editorial, formatting clarifications

gtfs-realtime/proto/gtfs-realtime.proto

@@ -1080,24 +1080,24 @@ message Stop {
 
 // NOTE: This field is still experimental, and subject to change. It may be formally adopted in the future.
 message TripModifications {
-	message Modification {
+  message Modification {
     // The stop selector of the first stop_time of the original trip that is to be affected by this modification.
     // Used in conjuction with `end_stop_selector`. 
-    //`start_stop_selector` is required and is used to define the reference stop used with `travel_time_to_stop`.
-		optional StopSelector start_stop_selector = 1;
+    // `start_stop_selector` is required and is used to define the reference stop used with `travel_time_to_stop`.
+    optional StopSelector start_stop_selector = 1;
 
     // The stop selector of the last stop of the original trip that is to be affected by this modification. 
     // The selection is inclusive, so if only one stop_time is replaced by that modification, `start_stop_selector` and `end_stop_selector` should be equivalent.
     // If no stop_time is replaced, `end_stop_selector` should not be provided. It's otherwise required.
-		optional StopSelector end_stop_selector = 2;
+    optional StopSelector end_stop_selector = 2;
 
     // The number of seconds of delay to add to all departure and arrival times following the end of this modification. 
-    //If multiple modifications apply to the same trip, the delays accumulate as the trip advances. 
-		optional int32 propagated_modification_delay = 3 [default = 0];
+    // If multiple modifications apply to the same trip, the delays accumulate as the trip advances. 
+    optional int32 propagated_modification_delay = 3 [default = 0];
 
     // A list of replacement stops, replacing those of the original trip. 
     // The length of the new stop times may be less, the same, or greater than the number of replaced stop times. 
-		repeated ReplacementStop replacement_stops = 4;
+    repeated ReplacementStop replacement_stops = 4;
 
     // An `id` value from the `FeedEntity` message that contains the `Alert` describing this Modification for user-facing communication.
     optional string service_alert_id = 5;
@@ -1113,7 +1113,7 @@ message TripModifications {
 
     // The following extension IDs are reserved for private use by any organization.
     extensions 9000 to 9999;
-	}
+  }
 
   message SelectedTrips {
     // A list of trips affected with this replacement.

gtfs-realtime/spec/en/trip-modifications.md

@@ -22,13 +22,13 @@ The scheduled stop times of each replacement trip are created from those of the
 ## Linkage to TripUpdates
 
 * A TripUpdate SHOULD be provided using a `ModifiedTripSelector` inside the TripUpdate's `TripDescriptor`. 
-    * When the TripUpdate refers to the replacement trip, the consumer should behave as if the static GTFS would have been modified with the TripModifications (e.g. `arrival_time`, `departure_time`, `stop_sequence`, `stop_id` on replacement stops)
-    * When providing a `ModifiedTripSelector`, the other fields of the `TripDescriptor` MUST be left empty, to avoid confusion by consumer that aren't looking for the `ModifiedTripSelector` value. 
-    * TripUpdate feeds providing updates with `ModifiedTripSelector` SHOULD also include a TripUpdate targetting clients that don't about TripModifications. In other words, there should be two TripUpdates : one for clients with modified trips (with `TripModifications`) and one for clients with the originial unmodified GTFS (without `TripModifications`)
-    * Providing a TripUpdate with the a `ModifiedTripSelector` is the only way to create predictions at replacement stops
+    * When the TripUpdate refers to the replacement trip, the consumer should behave as if the static GTFS would have been modified with the TripModifications (e.g. `arrival_time`, `departure_time`, `stop_sequence`, `stop_id` on replacement stops).
+    * When providing a `ModifiedTripSelector`, the other fields of the `TripDescriptor` MUST be left empty, to avoid confusion by consumers that aren't looking for the `ModifiedTripSelector` value. 
+    * TripUpdate feeds providing updates with `ModifiedTripSelector` SHOULD also include a TripUpdate targeting clients that don't support TripModifications. In other words, there should be two TripUpdates: one for clients with modified trips (with `TripModifications`) and one for clients with the originial unmodified GTFS (without `TripModifications`).
+    * Providing a TripUpdate with the a `ModifiedTripSelector` is the only way to create predictions at replacement stops.
 * If no such TripUpdate is found, TripUpdates for the original `trip_id` will apply to the modified trip. 
     * In this case, the static GTFS information used should be from the static GTFS before any TripModifications applied. 
-    * Real time can be available to the common stops between the previous trip and the new modified trip, no ETA is available at the replacement stops.
+    * Real time information can be available to the common stops between the previous trip and the new modified trip; however, no ETA would be available at the replacement stops.
 
 ##  Modification