Merge pull request #105 from OneBusAway/pretags

Be consistent about wrapping REST API params with `<pre>`  tags

src/api/where/methods/config.md

@@ -8,7 +8,7 @@ example_response_file: config.json
 
 ## Request Parameters
 
-* key - API key for authentication.
+* `key` - API key for authentication.
     * `https://api.pugetsound.onebusaway.org/api/where/config.json?&key=[API KEY GOES HERE]`
 
 

src/api/where/methods/report-problem-with-stop.md

@@ -12,20 +12,20 @@ example_response_file: report-problem-with-stop-1_75403.json
 
 ## Request Parameters
 
-* stopId - the trip id, encoded directly in the URL:
+* `stopId` - the stop id, encoded directly in the URL:
     * `http://api.pugetsound.onebusaway.org/api/where/report-problem-with-stop/[ID GOES HERE].xml`
-* code - a string code identifying the nature of the problem
+* `code` - a string code identifying the nature of the problem
     * `stop_name_wrong` - the stop name in OneBusAway differs from the actual stop's name
     * `stop_number_wrong` - the stop number in OneBusAway differs from the actual stop's number
     * `stop_location_wrong` - the stop location in OneBusAway differs from the actual stop's location
     * `route_or_trip_missing` - an expected route or trip is missing from the stop
     * `other` - catch-all for everythign else
-* userComment - additional comment text supplied by the user describing the problem
-* userLat - the reporting user's current latitude
-* userLon - the reporting user's current longitude
-* userLocationAccuracy - the reporting user's location accuracy, in meters
+* `userComment` - additional comment text supplied by the user describing the problem
+* `userLat` - the reporting user's current latitude
+* `userLon` - the reporting user's current longitude
+* `userLocationAccuracy` - the reporting user's location accuracy, in meters
 
-In general, everything but the stop id itself is optional, but generally speaking, providing more fields in the report
+In general, everything but the `stopId` itself is optional, but generally speaking, providing more fields in the report
 will make it easier to diagnose the actual underlying problem.  Note that while we record specific location information
 for the user, we do not store any identifying information for the user in order to make it hard to link the user to
 their location as some point in the future.

src/api/where/methods/report-problem-with-trip.md

@@ -12,26 +12,26 @@ example_response_file: report-problem-with-trip-1_79430293.json
 
 ## Request Parameters
 
-* tripId - the trip id, encoded directly in the URL:
+* `tripId` - the trip id, encoded directly in the URL:
     * `http://api.pugetsound.onebusaway.org/api/where/report-problem-with-trip/[ID GOES HERE].xml`
-* serviceDate - the service date of the trip
-* vehicleId - the vehicle actively serving the trip
-* stopId - a stop id indicating the stop where the user is experiencing the problem
-* code - a string code identifying the nature of the problem
+* `serviceDate` - the service date of the trip
+* `vehicleId` - the vehicle actively serving the trip
+* `stopId` - a stop id indicating the stop where the user is experiencing the problem
+* `code` - a string code identifying the nature of the problem
     * `vehicle_never_came`
     * `vehicle_came_early` - the vehicle arrived earlier than predicted
     * `vehicle_came_late` - the vehicle arrived later than predicted
     * `wrong_headsign` - the headsign reported by OneBusAway differed from the vehicle's actual headsign
     * `vehicle_does_not_stop_here` - the trip in question does not actually service the indicated stop
     * `other` - catch-all for everythign else
-* userComment - additional comment text supplied by the user describing the problem
-* userOnVehicle - true/false to indicate if the user is on the transit vehicle experiencing the problem
-* userVehicleNumber - the vehicle number, as reported by the user
-* userLat - the reporting user's current latitude
-* userLon - the reporting user's current longitude
-* userLocationAccuracy - the reporting user's location accuracy, in meters
+* `userComment` - additional comment text supplied by the user describing the problem
+* `userOnVehicle` - true/false to indicate if the user is on the transit vehicle experiencing the problem
+* `userVehicleNumber` - the vehicle number, as reported by the user
+* `userLat` - the reporting user's current latitude
+* `userLon` - the reporting user's current longitude
+* `userLocationAccuracy` - the reporting user's location accuracy, in meters
 
-In general, everything but the trip id itself is optional, but generally speaking, providing more fields in the report
+In general, everything but the `tripId` itself is optional, but generally speaking, providing more fields in the report
 will make it easier to diagnose the actual underlying problem.  Note that while we record specific location information
 for the user, we do not store any identifying information for the user in order to make it hard to link the user to
 their location as some point in the future.

src/api/where/methods/route-ids-for-agency.md

@@ -8,7 +8,7 @@ example_response_file: route-ids-for-agency-40.json
 
 ## Request Parameters
 
-* id - the id of the agency, encoded directly in the URL:
+* `id` - the id of the agency, encoded directly in the URL:
     * `http://api.pugetsound.onebusaway.org/api/where/route-ids-for-agency/[ID GOES HERE].xml?key=TEST`
 
 ## Response

src/api/where/methods/routes-for-agency.md

@@ -8,7 +8,7 @@ example_response_file: routes-for-agency-40.json
 
 ## Request Parameters
 
-* id - the id of the agency, encoded directly in the URL:
+* `id` - the id of the agency, encoded directly in the URL:
     * `http://api.pugetsound.onebusaway.org/api/where/routes-for-agency/[ID GOES HERE].xml`
 
 ## Response

src/api/where/methods/schedule-for-route.md

@@ -16,20 +16,20 @@ example_response_file: schedule-for-route-1_100223.json
 
 ## Response
 
-The intent of this response is to mimic a traditional schedule-table format for viewing a route. As such the entry includes traditional header information, as well as a section of concentrated schedule information (in the form of stopTripGroupings).
+The intent of this response is to mimic a traditional schedule-table format for viewing a route. As such the entry includes traditional header information, as well as a section of concentrated schedule information (in the form of `stopTripGrouping`s).
 
 The header information is:
 * `<routeId/>` - the route being looked into -  this information is presented in the format `[agency]_[routeIdentifier]`
 * `<scheduleDate/>` - the date being looked at  -  the date of service in milliseconds since the Unix epoch
 * `<serviceIds>` - the Service Ids which contain that route and are live on the specified date -  for more information see the [GTFS spec](http://code.google.com/transit/spec/transit_feed_specification.html)
 
-The entry also has concentrated schedule information in the form of stopTripGroupings. Each grouping includes:
-* `<directionId\>` - the direction the trips are heading -  for more information see the [GTFS spec](http://code.google.com/transit/spec/transit_feed_specification.html)
-* `<tripHeadsign\>` - the trip headsign - a string indicting the destination of the trip
-* `<stopIds\>` - an ordered list of stop Ids - Each id is of the format `[agency]_[stopIdentifier]`
-* `<tripIds\>` - a list of trip Ids that matched by shared direction- Each trip Id is of the format `[agency]_[tripIdentifier]`
-
+The entry also has concentrated schedule information in the form of `stopTripGrouping`s. Each grouping includes:
+* `directionId` - the direction the trips are heading -  for more information see the [GTFS spec](http://code.google.com/transit/spec/transit_feed_specification.html)
+* `tripHeadsign` - the trip headsign - a string indicting the destination of the trip
+* `stopIds` - an ordered list of stop Ids - Each id is of the format `[agency]_[stopIdentifier]`
+* `tripIds` - a list of trip Ids that matched by shared direction - Each `tripId` is of the format `[agency]_[tripIdentifier]`
 
 Alternate codes:
-404 - returned if the route ID in the request is not found
-510 - returned if the route has no schedules for the day requested
+
+* `404` - returned if the route ID in the request is not found
+* `510` - returned if the route has no schedules for the day requested

src/api/where/methods/schedule-for-stop.md

@@ -22,21 +22,21 @@ We break up the stop time listings in a couple of ways.  First, we split the sto
 
 Finally we get down to the unit of a stop time, as represented by the `<scheduleStopTime/>` element.  Each element has the following set of properties:
 
-* arrivalTime - time in milliseconds since the Unix epoch that the transit vehicle will arrive
-* departureTime - time in milliseconds since the Unix epoch that the transit vehicle will depart
-* tripId - the id for the trip of the scheduled transit vehicle
-* serviceId - the serviceId for the schedule trip (see the [GTFS spec](http://code.google.com/transit/spec/transit_feed_specification.html) for more details
+* `arrivalTime` - time in milliseconds since the Unix epoch that the transit vehicle will arrive
+* `departureTime` - time in milliseconds since the Unix epoch that the transit vehicle will depart
+* `tripId` - the id for the trip of the scheduled transit vehicle
+* `serviceId` - the serviceId for the schedule trip (see the [GTFS spec](http://code.google.com/transit/spec/transit_feed_specification.html) for more details
 
 In addition to all the `<scheduleStopTime/>` elements, the response also contains `<stopCalendarDay/>` elements which list out all the days that a particular stop has service.  This element has the following properties:
 
-* date - the date of service in milliseconds since the Unix epoch
-* group - we provide a group id that groups `<stopCalendarDay/>` into collections of days with similar service.  For example, Monday-Friday might all have the same schedule and the same group id as result, while Saturday and Sunday have a different weekend schedule, so they'd get their own group id.
+* `date` - the date of service in milliseconds since the Unix epoch
+* `group` - we provide a group id that groups `<stopCalendarDay/>` into collections of days with similar service.  For example, Monday-Friday might all have the same schedule and the same group id as result, while Saturday and Sunday have a different weekend schedule, so they'd get their own group id.
 
 In addition to all the `<scheduleStopTime/>` elements, the main entry also has the following properties:
 
-* date - the active date for the returned calendar
-* stopId - the stop id for the requested stop, which can be used to access the [`<stop/>` element](/api/where/elements/stop) in the `<references/>` section
-* timeZone - the time-zone the stop is located in
+* `date` - the active date for the returned calendar
+* `stopId` - the stop id for the requested stop, which can be used to access the [`<stop/>` element](/api/where/elements/stop) in the `<references/>` section
+* `timeZone` - the time-zone the stop is located in
 
 ### Proposed Additions