anchor.diff:  * NotSupportedQuery     (`422`). The implementation does not support the query issued.
   * NoResourcesAvailable  (`413`). There are no server resources to fulfill the client request. 
   
  -New error codes could be defined in new iterations of this specification.
  +New error codes may be defined in new iterations of this specification.
   
   ## Geospatial properties of entities
   
  -The geospatial properties of a context entity can be represented by means of regular context attributes.
  +The geospatial properties of a context entity can be represented by means of regular
  +context attributes.
   The provision of geospatial properties enables the resolution of geographical queries.
   
   Two different syntaxes must be supported by compliant implementations: 
   
  -* *Simple Location Format*. It is meant as a very lightweight format that developers and users can quickly
  -and easily add to their existing entities with little effort.
  -
  -* *GeoJSON*.  [GeoJSON](https://tools.ietf.org/html/draft-butler-geojson-06)
  -is a geospatial data interchange format based on the JavaScript Object Notation (JSON). GeoJSON provides greater flexibility
  -allowing the representation of point altitudes or even more complex geospatial shapes, for instance
  -[multi geometries](http://www.macwright.org/2015/03/23/geojson-second-bite.html#multi-geometries).
  -
  -Client applications are responsible for defining which entity attributes convey geospatial properties (by providing
  -an appropriate NGSI attribute type). Typically it will be an entity attribute named `location`,
  -but nothing prevents use cases where an entity contains more than one geospatial attribute. For instance,
  -locations specified at different granularity levels or provided by different location methods with different accuracy. 
  -Nonetheless, it is noteworthy the fact that spatial properties
  +* *Simple Location Format*. It is meant as a very lightweight format for developers and users to
  +  quickly and easily add to their existing entities.
  +
  +* *GeoJSON*.  [GeoJSON](https://tools.ietf.org/html/draft-butler-geojson-06) is a geospatial data
  +  interchange format based on the JavaScript Object Notation (JSON).
  +  GeoJSON provides greater flexibility allowing the representation of point altitudes or even more
  +  complex geospatial shapes, for instance
  +  [multi geometries](http://www.macwright.org/2015/03/23/geojson-second-bite.html#multi-geometries).
  +
  +Client applications are responsible for defining which entity attributes convey geospatial properties
  +(by providing an appropriate NGSI attribute type). Typically this is an entity attribute named
  +`location`, but nothing prevents use cases where an entity contains more than one geospatial
  +attribute. For instance, locations specified at different granularity levels or provided by different
  +location methods with different accuracy. 
  +Nonetheless, it is noteworthy that spatial properties
   need special indexes which can be under resource constraints imposed by backend databases.
   Thus, implementations may raise errors when spatial index limits are exceeded.
  -The recommended HTTP status code for those situations is ``413``, *Request entity too large*, and the reported error
  -on the response payload must be ``NoResourcesAvailable``.
  -
  -*Note: At the time of writing it is still under discussion if supporting both syntaxes is really needed* 
  +The recommended HTTP status code for those situations is ``413``, *Request entity too large*, and the
  +reported error on the response payload must be ``NoResourcesAvailable``.
  +
  +*Note: At the time of writing it is still under discussion whether supporting both syntaxes is
  +really needed* 
   
   ### Simple Location Format
   
  -Simple Location Format supports basic geometries ( *point* , *line* , *box* , *polygon* ) and covers the typical
  -use cases when encoding geographical locations. It has been inspired by [GeoRSS Simple](http://www.georss.org/simple.html).
  -
  -It is noteworthy that the Simple Location Format is not intended to represent complex positions on Earth surface.
  -For instance, those applications which require to capture altitude coordinates will have to use GeoJSON as
  +Simple Location Format supports basic geometries (*point* , *line* , *box* , *polygon*) and covers
  +the typical use cases when encoding geographical locations. It has been inspired by
  +[GeoRSS Simple](http://www.georss.org/simple.html).
  +
  +It is noteworthy that the Simple Location Format is not intended to represent complex positions on
  +Earth surface.
  +For instance, applications that require to capture altitude coordinates will have to use GeoJSON as
   representation format for the geospatial properties of their entities. 
   
  -A context attribute  which represents a location encoded using the Simple Location Format
  +A context attribute representing a location encoded with the Simple Location Format
   must conform to the following syntax:
   
  -* The attribute type must be one of the following values: (`geo:point`, `geo:line`, `geo:box` or `geo:polygon`).
  -* The attribute value must be a list of coordinates. By default coordinates will be defined
  -using the [WGS84 Lat Long](https://en.wikipedia.org/wiki/World_Geodetic_System#WGS84),
  -[EPSG::4326](http://www.opengis.net/def/crs/EPSG/0/4326) coordinate reference system (CRS),
  -with latitude and longitude units of decimal degrees. Such coordinate list will allow to encode the geometry
  -specified by the `type` attribute and will be encoded according with the specific rules defined below:
  +* The attribute type must be one of the following values: (`geo:point`, `geo:line`, `geo:box` or 
  +  `geo:polygon`).
  +* The attribute value must be a list of coordinates. By default, coordinates are defined
  +  using the [WGS84 Lat Long](https://en.wikipedia.org/wiki/World_Geodetic_System#WGS84),
  +  [EPSG::4326](http://www.opengis.net/def/crs/EPSG/0/4326) coordinate reference system (CRS),
  +  with latitude and longitude units of decimal degrees. Such coordinate list allow to encode
  +  the geometry specified by the `type` attribute and are encoded according to the specific
  +  rules defined below:
   
     * Type `geo:point`:   the attribute value must contain a string containing a
  -  valid latitude-longitude pair, separated by a comma. 
  +    valid latitude-longitude pair, separated by comma.
     * Type `geo:line`:    the attribute value must contain a string array of
  -  valid latitude-longitude pairs. There must be at least two pairs.
  +    valid latitude-longitude pairs. There must be at least two pairs.
     * Type `geo:polygon`: the attribute value must contain a string array
  -  of valid latitude-longitude pairs.
  -There must be at least four pairs, with the last being identical to the first
  -(so a polygon has a minimum of three actual points).
  -Coordinate pairs should be properly ordered so that the line segments
  -that compose the polygon remain on the ​outer ​edge of the area defined.
  -For instance, the following path, ```[0,0], [0,2], [2,0], [2, 2]```, is an example of an invalid polygon definition. 
  -Implementations should raise an error when none of the former conditions are met by input data. 
  -  * Type `geo:box`:     A bounding box is a rectangular region, often used to define the extents of a map or
  -a rough area of interest. A box is represented by a two-length string array of latitude-longitude pairs.
  -The first pair is the lower corner, the second is the upper corner.
  +    of valid latitude-longitude pairs.
  +    There must be at least four pairs, with the last being identical to the first
  +    (so a polygon has a minimum of three actual points).
  +    Coordinate pairs should be properly ordered so that the line segments
  +    that compose the polygon remain on the outer edge of the defined area.
  +    For instance, the following path, ```[0,0], [0,2], [2,0], [2, 2]```, is an example of an invalid
  +    polygon definition. 
  +    Implementations should raise an error when none of the former conditions are met by input data. 
  +  * Type `geo:box`:     A bounding box is a rectangular region, often used to define the extents of a
  +    map or a rough area of interest. A box is represented by a two-length string array of
  +    latitude-longitude pairs.
  +    The first pair is the lower corner, the second is the upper corner.
   
   Note: Circle geometries are not supported, as the [literature](https://github.com/geojson/geojson-spec/wiki/Proposal---Circles-and-Ellipses-Geoms#discussion-notes)
   describes different shortcomings for implementations. 
  
positive.code: 
  ## Virtual Attributes
  
  There are entity properties that are not directly modificable by NGSIv2 clients, but that can be rendered
  by NGSIv2 servers to provide extra information. From a representation point of view, they are like
  regular attributes, with name, value and type.
  
  Virtual attributes are not rendered by default. In oder to render an specific attribute, add its name
  to the `options` URL parameter.
  
  The list of virtual attributes is the following:
  
  * `dateCreated` (type: `date`): entity creation date as ISO 8601 string.
  * `dateModified` (type: `date`): entity modification date as ISO 8601 string.
  
  As regular attributes, they can be  used in `attrs`, `q` filters and `orderBy`. However, they cannot be used
  in resource URLs.
  
  
  ## Field syntax restrictions
  
  Fields used as identifiers in the NGSIv2 API follow special rules regarding allowed syntax. These rules applies to:
  
  * Entity id
  * Entity type
  
negative.code: }
  ```
  
  Notifications must include a `Ngsiv2-AttrsFormat` HTTP header with the value of the format of the
  associated subscription, so that the notification receiver is aware of the format without
  needing to process the notification payload.
  
  ## Custom Notifications
  
  NGSIv2 clients can customize HTTP notification messages using a simple template mechanism. The
  `notification.httpCustom` property of a subscription allows to specify the following fields
  to be templatized:
  
  * `url`
  * `headers` (both header name and value can be templatized)
  * `qs` (both parameter name and value can be templatized)
  * `payload`
  
  The fifth field `method`, lets the NGSIv2 clients select the HTTP method to be used for delivering
  the notification, but note that only valid HTTP verbs can be used: GET, PUT, POST, DELETE, PATCH,
  HEAD, OPTIONS, TRACE, and CONNECT.
  
  
  Macro substitution for templates is based on the syntax `${..}`. In particular:
  
  