Review and tweak Image API change-log. Minor changes only

Couple more tweaks

Author: zimeon

source/api/image/2.0/change-log.md

@@ -12,15 +12,13 @@ pre: draft
 
 This document is a companion to the [IIIF Image API Specification, Version 2.0][api]. It describes the significant changes to the API since [Version 1.1][api-11]. The changes are broken into two groups: [Breaking Changes][breaking-changes], i.e. those that are not backwards compatible from either a client or server perspective (or both); and [Other Changes][other-changes], i.e. those that are backwards compatible. The latter group consists mostly of new features.
 
-In addition to the changes described above:
+In addition to changes in the API, the specification documents have been changed as follows:
 
   * The ordering of the major sections in the specification document has been adjusted for better flow.
   * The use of [RFC 2119 keywords][rfc-2119] has been made more consistent.
   * Language has been adjusted to make the document less developer-centric.
 
-These changes will not be described further in this document.
-
-With the [2.0 Release of the IIIF Image API][api], the editors will begin using [Semantic Versioning][semver] to enumerate releases. As the API relies on predictable URI patterns in several areas, careful choices have been made about which details of the version will be expressed and where. This is explained in [Appendix B][versioning].
+With the [2.0 Release of the IIIF Image API][api], [Semantic Versioning][semver] is used to enumerate releases. As the API relies on predictable URI patterns in several areas, careful choices have been made about which details of the version will be expressed and where. This is explained in [Appendix B][versioning].
 
 ## Table of Contents
 {:.no_toc}
@@ -34,11 +32,11 @@ With the [2.0 Release of the IIIF Image API][api], the editors will begin using
 
 Previous versions of the specification used "grey" (not "gray") but "color" (not "colour"). While this does reflect the international nature of IIIF, it is not terribly consistent. From this release `grey` is now `gray`.
 
-There was also confusion among users as to the meaning of `native`. The API does not recognize the notion of a source image, and the label `native` was tied too closely to such an idea. In 2.0 `native` has been replaced with `default`, with the implication that the server should return the image in a default quality, but the API provides no instructions as to how this decision is made (in the future, for example, authorization may determine the default quality).
+There was also confusion among users as to the meaning of `native`. The API does not recognize the notion of a source image, and the label `native` was tied too closely to such an idea. In 2.0 `native` has been replaced with `default`, with the implication that the server should return the image in a default quality. The API does not specify how this decision is made (in the future, for example, authorization may determine the default quality).
 
 ### Added `profile` property to Image Information document
 
-This is a response to several requests for the ability to describe the capabilites of a server or a particular image with finer granularity than that of the compliance levels. For example, a server may be completely compliant with level 1, but also support the `!w,h` syntax for specifying the size, which is a level 2 feature. This capability can be exposed using the `supports` property with the `profile` property.
+This is a response to several requests for the ability to describe the capabilities of a server or a particular image with finer granularity than that of the compliance levels. For example, a server may be completely compliant with level 1, but also support the `!w,h` syntax for specifying the size, which is a level 2 feature. This capability can be exposed using the `supports` property with the `profile` property.
 
 The `supports` property may also be used to describe extension features. See [5.2 Extensions][extensions] for details.
 
@@ -56,26 +54,27 @@ The compliance URIs have been moved into the `http://iiif.io` domain. They now r
 
 ### Dropped Support for Content Negotiation and Default Image Format
 
-As of this version, a client must specify the format of the image as a file-like suffix on the URI, e.g. `default__.jpg__`. There are several reasons for this change:
+As of this version, a client must specify the format of the image as a file-extension like suffix on the URI (e.g. `.jpg`). There are several reasons for this change:
 
  * This a typical convention employed by image processing utilities, (cf. [ImageMagick][imagemagick-output], [Pillow][pillow], [Kakadu][kdu-usage], and most others).
- * The formats in which the image is available are explicitly enumerated by the info.json document for an image and/or the server compliance level document. A client should never need to guess or let the server decide as `jpg` is always required.
+ * The formats in which the image is available are explicitly enumerated by the `info.json` document for an image and/or the server compliance level document. A client should never need to guess or let the server decide.
+ * The `jpg` format must be supported at all compliance levels and thus applications requiring it can rely upon its availability.
  * Static image files on the web typically have file extensions that indicate the format, and there was never a clear use case for when a client would prefer content negotiation over expressing the format in the URI.
 
-Servers should now return a 400 (Bad Request, if possible) or else a 404 (Not found) when an image request does not include a format suffix.
+Servers should now return a 400 (Bad Request) if possible, or else a 404 (Not Found) when an image request does not include a format suffix.
 
 ### Limited Error Response Code Requirements for Level 0
 
-Level-0-compliant servers may always return a 404 (Not Found) error for any bad requests. While this is not brought out explicitly in the document, the RFC keyword describing when to return a 400 (Bad Request) response has been reduced to "should".
+Servers compliant at level 0 may always return a 404 (Not Found) error for any bad requests. While this is not brought out explicitly in the document, the RFC keyword describing when to return a 400 (Bad Request) response has been reduced to "should".
 
 ## Other Changes
 
 ### Added Canonical URI Form
 
 There are potentially several ways to request the same image, and two cases arose in which it makes sense to have a canonical form of image request URI:
 
-  * A level-0-compliant server based on pre-made images on a file system needs to know whether to use percent or pixels and the directory names, specify width only, width and height, etc.
-  * A level-2-compliant server may want to server may want to redirect to the canonical syntax for better cache performance.
+  * A server compliant at level 0 based on pre-made images on a file system needs to know which URI form to use in order to avoid either failing to support applications or having to generate multiple files for the same image. For example, are the region and size best specified by percent or pixel dimensions or `full`?
+  * A more capable server may redirect to the canonical syntax for better cache performance.
 
 The canonical URI for an image may be specified in an HTTP Link Header with the attribute `rel=canonical`. See [Section 4.7 Canonical URI Syntax][canonical-uris] for details.
 
@@ -85,21 +84,21 @@ The value of this property is always the URI `http://iiif.io/api/image` which pu
 
 The `protocol` property is required at all levels of compliance.
 
-### Drop Rotation to Level 2 Compliance
+### Drop Rotation from Level 1 Compliance
 
 Rotation in multiples of 90 was previously a level 1 requirement. As this can be--and frequently is--handled in the browser via the HTML 5 `<canvas>` element or CSS instructions, the editors felt this was an unnecessary barrier to level 1 compliance.
 
 ### Added `sizes` property to Image Information document
 
-Servers that do not support arbitrary size parameters for image requests may still wish make multiple sizes of an image available. The sizes that are available may be listed using the `w,h`syntax in the `sizes` property. Even when a server does support arbitrary resizing, it may be useful to report pre-cached or otherwise recommended sizes of an image, e.g. thumbnails.
+Servers that do not support arbitrary size parameters for image requests may still wish make multiple sizes of an image available. The sizes that are available may be listed using the `w,h` syntax in the `sizes` property. Even when a server does support arbitrary resizing, it may be useful to report pre-cached or otherwise recommended sizes of an image, e.g. thumbnails.
 
 ### Published JSON-LD Context
 
-The [context document][context] for the info.json document was never published. It is now available.
+The [context document][context] for the `info.json` document was not published for version 1.1. It is now available.
 
-### Support JSON-LD ContentType/Accept Header
+### Support JSON-LD Content-Type/Accept header
 
-As transition to JSON-LD (since it is not fully supported by browsers), clients that favor the "application/ld+json" media type in the accept header of their request may receive this as the content-type of the response. Also note that it is recommended that the server include the context URI in a Link header of the response if the request was for for "application/json". See [Section 5][info-request] and the documents to which it links for further details.
+As transition to JSON-LD (since it is not fully supported by browsers), clients that favor the "application/ld+json" media type in the accept header of their request may receive this as the Content-Type of the response. Also note that it is recommended that the server include the context URI in a Link header of the response if the request was for for "application/json". See [Section 5][info-request] and the documents to which it links for further details.
 
 [api-11]: /api/image/1.1/ "Image API 1.1"
 [api-compliance]: /api/image/2.0/#compliance-levels "Image API 6. Compliance Levels"