openaustralia/planningalerts

:markdown
  <h3 id="section4.2">4.2 Feed</h3>

  Any compliant source of application tracking data is referred to as a *feed*. A feed is defined by a standard web address of the form:

= image_tag "atdis/image_2.png", alt: "Feed web address format"
%p{ align: "center" } Figure 3: Feed web address format

:markdown
  **Where**

  * **Protocol**: assume HTTP, but HTTPS can be used by a Council if required
  * **Web address**: the fully qualified web host name for the Complying Authority. By convention, this should
  be the same as the URL used to access the Council's publicly available web site.
  * **Feed prefix**: component of the URI that indicates a complying feed.
  * **Schema version**: component of the feed prefix that indicates the version of the schema offered by the
  feed.
  * **Unique Authority identifier**: The UAI uniquely identifies an authority for applications published by an
  ATDIS-compliant authority. This allows for applications within one LGA to be referenced uniquely by documents within another authority without the need to ensure that dat_id values are unique across all participants.
  * **Globally Unique DAT Id**: When combined wit the UAI, the dat_id for an application creates a globally unique identifier for an application that is portable between LGA jurisdictions.

  **Notes**

  * There are a number of options for how the schema version number might be encoded into the feed URL. The above format (where the version is encoded into the URI) is the simplest mechanism, but it is also possible to encode version number with an HTTP header variable, with a query string parameter, or by using content negotiation. There is a vibrant and passionate debate about the best way to version URLs for access to resources that shows no prospect of being settled soon. Therefore, for the purposes of ATDIS-1.0.2, a simple URI-encoded version string is proposed. If content negotiation becomes the preferred standard, then this it is relatively easy to change the prefix in a future release.
  * Given a version of the specification of the form MAJOR.minor.patch, it is assumed that all patch versions of the same major/minor version remain semantically and syntactically compatible with each other. Minor may introduce new items but will not remove any existing items. Major versions may make changes to the schema that are not backwards compatible.