Clarify behaviour and linkage to TripUpdates

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

@@ -12,15 +12,19 @@ The modification is in effect on all of the listed service\_dates, until it is r
 
 There MAY be multiple `TripModifications` for a given stop pattern. It may be desirable to split the trips into multiple modifications e.g. if the `propagated_modification_delay` changes significantly, over the course of the detour.
 
-The trips created through GTFS-TripModifications modify and replace each specified `trip_id`, and don't create a copy or additional run.
+The trips created through GTFS-TripModifications modify and replace each specified `trip_id`, and don't create a copy or additional run. Modification are applied on the schedule information, like if a static GTFS (CSV) was modified. 
 
-The scheduled stop times of each replacement trip are created from those of the affected trip, by performing the changes listed in modifications. Stop sequences are assigned from 1 to n, increasing by 1 for each stop in the trip. A `TripUpdate` message must be provided to publish real-time arrival/departure times for the replacement trip.
+The scheduled stop times of each replacement trip are created from those of the affected trip, by performing the changes listed in modifications. `stop_sequence` for all stop times are replaced by a new value of 1 to n, starting with 1 on the first stop_time and increasing by 1 for each stop in the trip. The trip ID is also replaced by a replacement trip ID (`modifications_id` + `_` + `trip_id`). A `TripUpdate` message must be provided to publish real-time arrival/departure times for the replacement trip.
 
 
 ## Linkage to TripUpdates
 
-* A TripUpdate SHOULD be provided using the replacement trip ID (`modifications_id` + `_` + `trip_id`). The TripUpdate MAY provide an ETA at the replacement stops.
-* If no such TripUpdate is found, TripUpdates for the original `trip_id` will apply to the modified trip. In this case, no ETA is available at the replacement stops.
+* A TripUpdate SHOULD be provided using the replacement trip ID (`modifications_id` + `_` + `trip_id`). 
+    * When the TripUpdate refers to the replacement trip ID, 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)
+    * Providing a TripUpdate with the replacement trip ID 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.
 
 ##  Modification
 
@@ -29,9 +33,11 @@ A `Modification` message replaces a span of n stop times (`num_stops_replaced`)
 The sequence of `replacement_stops` may be of arbitrary length. For example, 3 stops could be replaced by 2, 4, or 0 stops as the situation may require.
 
 ![](images/trip_modification.png)
+
 _An example showing the effect of a modification on a particular trip. This modification may also be applied to several other trips._
 
 ![](images/propagated_delay.png)
+
 _Propagated detour delays affect all stops following the end of a modification. If a trip has multiple modifications, the delays are accumulated._
 
 ## ReplacementStop
@@ -45,6 +51,7 @@ The `departure_time` always equals the `arrival_time`.
 The optional fields of [`stop_times.txt`](https://github.com/google/transit/blob/master/gtfs/spec/en/reference.md#stop_timestxt) in the (CSV) GTFS specification are all set to their default values.
 
 ![](images/first_stop_reference.png)
+
 _If a modification affects the first stop of the trip, that stop also serves as the reference stop of the modification._
 
 ## Shape