Merge pull request #265 from IIIF/draft2

Draft 2 news to _posts. Closes #263.
IIIF · Jul 4, 2014 · b2fa537 · b2fa537
2 parents 5d1ebf4 + c54fe81
commit b2fa537
Show file tree

Hide file tree

Showing 6 changed files with 99 additions and 14 deletions.
diff --git a/source/_posts/2014-06-01-drafts-released.md b/source/_posts/2014-06-01-drafts-released.md
@@ -1,5 +1,5 @@
 ---
-title: IIIF Image and Presentation API Drafts Releases
+title: IIIF Image and Presentation API Drafts Released
 author: Jon Stroop
 date: 2014-05-29
 tags: [specifications, image-api, presentation-api, announcements]

diff --git a/source/_posts/2014-07-01-draft-2s-released.md b/source/_posts/2014-07-01-draft-2s-released.md
@@ -0,0 +1,52 @@
+---
+title: IIIF Image and Presentation API Second Drafts Released
+author: Robert Sanderson, Jon Stroop, Simeon Warner
+date: 2014-07-01
+tags: [specifications, image-api, presentation-api, announcements]
+layout: post
+---
+
+After a month of public testing and feedback, the IIIF Editors are pleased to announce second draft revisions of the International Image Interoperability Framework Image and Presentation (formerly 'Metadata') API specifications.
+
+ * [IIIF Image API 2.0.0-draft2](/api/image/2.0/)
+ * [IIIF Presentation API 2.0.0-draft2](/api/presentation/2.0/)
+
+Since the release of the first drafts. a few significant changes have been made:
+
+### Image API
+
+ * Added `services` to info.json [ [Changes](https://github.com/IIIF/iiif.io/commit/801e9e1628f34c77001d2b151df8efb88e1c688a) \| [Discussion](https://groups.google.com/d/msg/iiif-discuss/4rp3OvK0jtI/Gow0pF45bMIJ) ]
+ * Added mirroring option to rotation syntax [ [Changes](https://github.com/IIIF/iiif.io/commit/93869af7e4fee290c044392e0858d1805cf26e80) \| [Discussion](https://groups.google.com/forum/#!topic/iiif-discuss/J7u9cyKZKU4) ]
+ * Added clarification of `default` quality [ [Changes](https://github.com/IIIF/iiif.io/commit/dd54d7dfaf4bd2b5ade8b1ab16b8ada8687eb7bb) ] and rotation/background [ [Changes](https://github.com/IIIF/iiif.io/commit/b2d6bfe59bd3fdbe3147c88333d2c922f4caf1d6) \| [Discussion](https://groups.google.com/forum/#!topic/iiif-discuss/AnXBvw_gVI0) ]
+ * Expanded `info.json` descriptions [ [Changes](https://github.com/IIIF/iiif.io/commit/044da46a2eea17374f2604036bd4c066788cf95b) ]
+ * Clarified and cleanly separated information about support for tiles vs. support for preferred sizes in `info.json` [ [Changes](https://github.com/IIIF/iiif.io/commit/15c8445403d8ed72f300f8a3da6de2ce05cc8475) \| [Discussion](https://groups.google.com/forum/#!topic/iiif-discuss/YOAAcALqoAE) ]
+
+
+### Presentation API
+
+* Added server side rotation option with iiif:ImageApiSelector [ [Changes](https://github.com/IIIF/iiif.io/commit/f94fda233731b4140a922ee673f09fd2f04dc053) \| [Discussion](https://groups.google.com/forum/#!topic/iiif-discuss/k2Lu6INn5KM) ]
+* Improved JSON to RDF mapping [ [Changes](https://github.com/IIIF/iiif.io/commit/522f1664f244d3a6f35b05db4d66a7833b9b6bd2) ]
+* Minor Clarifications:
+  * Cannot reference locations outside of a Canvas
+  * Reduced focus on presenting digitized physical objects
+  * Explicit definition of physical scale algorithm
+
+As always, we welcome your feedback, questions, and use cases, and encourage you to submit them to the [IIIF Discussion Listserv](mailto:{{ site.data.organization.email }}). Drafts will be kept open for comment until the beginning of August, with the goal of final release in September. However, we would appreciate feedback early in order to work on and gain consensus for any necessary changes.
+
+Sincerely,
+
+The IIIF Image and Presentation API Editors
+Benjamin Albritton
+Michael Appleby
+Robert Sanderson
+Stuart Snydman
+Jon Stroop
+Simeon Warner
+
+cc:
+[email protected]
+[email protected]
+[email protected]
+[email protected]
+[email protected]
+[email protected]
diff --git a/source/api/image/2.0/change-log.md b/source/api/image/2.0/change-log.md
@@ -7,10 +7,10 @@ tags: [specifications, image-api, change-log]
 major: 2
 minor: 0
 # no patch
-pre: draft
+pre: draft2
 ---
 
-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.
+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 three groups: [Breaking Changes][breaking-changes], i.e. those that are not backwards compatible from either a client or server perspective (or both) and mostly consists of new features; [Other Changes][other-changes], i.e. those that are backwards compatible; and [Deferred Changes][deferred-changes], i.e. those that will be made in a future iteration of the Image API.
 
 In addition to changes in the API, the specification documents have been changed as follows:
 
@@ -40,6 +40,11 @@ This is a response to several requests for the ability to describe the capabilit
 
 The `qualities` and `formats` properties have been moved into the object referenced in `profile`.
 
+### Added `tiles` property to Image Information document
+
+A `tiles` property was added to the top level of the JSON in the Image Information document response.  The rationale was to promote consistency between information about tiles (regions of an image at different sizes) and the different sizes available (see `sizes` below), to clarify that the `scale_factors` are related to tiles rather than the complete image, and to allow different tile sizes at different scale factors.  The property is a list of JSON objects, with `height`, `width` and `scale_factors` properties.  This change therefore renames `tile_height` and `tile_width`, and moves them along with `scale_factors` into the new structure.  The `height` property is now optional, defaulting to the same as `width`.  This makes the default of square tiles easier to record.
+
+
 ### Required <abbr title="Cross-Origin Resource Sharing">CORS</abbr> for level 1 Compliance
 
 One of the core purposes--if not _the_ core purpose--of IIIF is to share images between institutions. This is is impossible without the ability to exchange images and metadata across different HTTP domains. CORS is the standard way to do this.
@@ -97,8 +102,9 @@ In order to provide the same extension point as is in the [Presentation API][pre
 
 ### 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 an array of JSON objects in the `sizes` property of the top level of the Image Information response.  The object has `height`, `width` and `viewing_hint` properties.  The `viewing_hint` property was added from the Presentation API to allow the server to provide a hint to the client about the intended use of the given image size, such as 'thumbnail' or 'icon'.
 
+Even when a server does support arbitrary resizing, it may be useful to report pre-cached or otherwise recommended sizes of an image.
 
 
 ### Published JSON-LD Context
@@ -109,6 +115,19 @@ The [context document][context] for the `info.json` document was not published f
 
 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.
 
+### Background Color for non-90 degree Rotations
+
+Clarified that clients should request image formats capable of transparent backgrounds when rotation is not a multiple of 90 degrees, and that servers should return transparent backgrounds for such images.  For formats that do not support transparent backgrounds, no requirements are specified.
+
+
+## Deferred Changes
+
+### Add Rights Information
+
+A proposal was made to add rights level information from the [Presentation API][prezi-api] to the Image Information response for images to avoid requiring support for both APIs just to give a license or attribution statement for the image.  This change was deferred until the next version of the API to coincide with the introduction of Authentication and Authorization information, and to allow extra time to gather use cases and requirements.
+
+
+
 [api-11]: /api/image/1.1/ "Image API 1.1"
 [api-compliance]: /api/image/2.0/#compliance-levels "Image API 6. Compliance Levels"
 [api]: /api/image/2.0/ "Image API 2.0"

diff --git a/source/api/image/2.0/index.md b/source/api/image/2.0/index.md
@@ -1,13 +1,13 @@
 ---
 title: "Image API 2.0 - DRAFT"
-title_override: "IIIF Image API 2.0 - DRAFT"
+title_override: "IIIF Image API 2.0 - DRAFT 2"
 id: image-api
 layout: spec
 tags: [specifications, image-api]
 major: 2
 minor: 0
 patch: 0
-pre: draft1
+pre: draft2
 ---
 
 ## Status of this Document
@@ -690,7 +690,8 @@ Many thanks to  Ben Albritton, Matthieu Bonicel, Anatol Broder, Kevin Clarke, To
 
 | Date       | Description |
 | ---------- | ----------- |
-| 2014-05-XX | Version 2.0 (Voodoo Bunny) RFC [View change log][change-log] |
+| 2014-07-01 | Version 2.0-draft2 (Voodoo Bunny) RFC [View change log][change-log] |
+| 2014-06-01 | Version 2.0-draft (Voodoo Bunny) RFC |
 | 2013-09-17 | Version 1.1 released. |
 | 2013-09-04 | Added @context to Image Information Request table in section 5. |
 | 2013-06-26 | Changed quality parameter definitions in section 4.4. |

diff --git a/source/api/presentation/2.0/change-log.md b/source/api/presentation/2.0/change-log.md
@@ -7,15 +7,15 @@ tags: [specifications, presentation-api, change-log]
 major: 2
 minor: 0
 # no patch
-pre: draft
+pre: draft2
 ---
 
 This document is a companion to the [IIIF Presentation API Specification, Version 2.0][prezi-api]. It describes the significant changes to the API since [Version 1.0][prezi-api-10]. 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); [Other Changes][other-changes], i.e. those that are backwards compatible. A third section, [Deferred Proposals][deferred-proposals], lists proposals that have been discussed but did not make it into this version of the specification.
 
 In addition to changes in the API, the specification documents have been changed as follows:
 
   * The use of [RFC 2119 keywords][rfc-2119] has been made more consistent.
-  * Language has been adjusted to make the document less focused on paged objects.
+  * Language has been adjusted to make the document less focused on paged, digitized objects.
   * [Semantic Versioning][semver] will be used to enumerate releases.
 
 ## Table of Contents
@@ -65,6 +65,10 @@ Several new fields were added:
 
 In order to manage requests for features that are not universally applicable, but still useful, the service construction that was previously under-specified has been extended to allow additional external specifications to be embedded or referenced.  Services are now listed in an annex document, and include the oft-discussed geo-tagging and physical dimensions features.
 
+### Server-side Image Rotation Option
+
+Added and described an Open Annotation Selector object that allows specifying the parameters for an Image API URI separately.  The original use case was server side rotation of a segment image, however all of the parameters could be useful in different situations.
+
 ### Start Canvas
 
 An additional value of `start` was added to the `viewing_hint` value enumeration, to be used on a canvas to assert that it's the one to be rendered to the user first, regardless of its position in the Sequence.
@@ -77,6 +81,10 @@ An additional value of `top` was added to the `viewing_hint` value enumeration,
 
 In 1.0 it was not possible to add most of the fields to content resources.  This was not for any good reason, and the restrictions were lifted.
 
+### Extra-Canvas Coordinates
+
+Clarified that any reference to a location outside of the dimensions of a Canvas is an error.
+
 ## Deferred Proposals
 
 ### Zones
@@ -93,16 +101,20 @@ Only canvases may list their annotations, and thus it is impossible to refer to
 
 ### Target Audience
 
-Particularly in the teaching and learning domain, it may be useful to specify the intended audience of resources.  For commentary annotations this is important, and not covered in the base Open Annotation specification.  It was decided to defer this until the Open Annotation community can determine a resolution to be adopted, but to promote use cases and existing solutions such as the IDPF use of schema.org's Audience classes.  Also, not backwards incompatible and no clients are ready to use it yet.
+Particularly in the teaching and learning domain, it may be useful to specify the intended audience of resources.  For commentary annotations this is important, and not covered in the base Open Annotation specification.  It was decided to defer this until the Open Annotation community can determine a resolution to be adopted, but to promote use cases and existing solutions such as the IDPF use of schema.org's Audience classes.  Also, it is backwards compatible and no clients are ready to use it yet.
 
 ### Compliance
 
-The Image API has a very well formed set of compliance requirements.  The Presentation API, conversely, does not have any.  This was not seen as a requirement that needed to be solved for 2.0, and was deferred for future work.
+The Image API has a very well formed set of compliance requirements.  The Presentation API, conversely, does not have any. This was not seen as a requirement that needed to be solved for 2.0, and was deferred for future work.
 
 ### Explicit Protocol
 
 The Image API in 2.0 has a protocol field that makes the assertion that the `info.json` document is part of the IIIF Image API protocol.  The Presentation API does not have this field.  There were no features or implementations identified that would make use of the field, and as it will be backwards compatible it was deferred until a requirement is expressed.
 
+### Minimum/Maximum Size Bounds for Annotation Rendering
+
+The content or commentary resources linked via annotations to a Canvas may be only useful to render at certain sizes, such as trying to render an image below 10 pixels width or text at less than 4 points.  While theoretically useful, no real world use cases have been presented that would justify its inclusion.  As a backwards compatible new feature, it was deferred until a requirement is expressed. 
+
 
 [api-11]: /api/image/1.1/ "Image API 1.1"
 [api-compliance]: /api/image/2.0/#compliance-levels "Image API 6. Compliance Levels"

diff --git a/source/api/presentation/2.0/index.md b/source/api/presentation/2.0/index.md
@@ -1,13 +1,13 @@
 ---
 title: "Presentation API 2.0 - DRAFT"
-title_override: "IIIF Presentation API 2.0 - DRAFT"
+title_override: "IIIF Presentation API 2.0 - DRAFT 2"
 id: presentation-api
 layout: spec
 tags: [specifications, presentation-api]
 major: 2
 minor: 0
 patch: 0
-pre: draft1
+pre: draft2
 ---
 
 ## Status of this Document
@@ -1368,7 +1368,8 @@ Many thanks to Matthieu Bonicel, Tom Cramer, Ian Davis, Markus Enders, Renhart G
 
 | Date       | Description                                        |
 | ---------- | -------------------------------------------------- |
-| 2014-06-01 | Version 2.0.0-draft (Triumphant Giraffe) RFC [View change log][change-log] |
+| 2014-07-01 | Version 2.0.0-draft2 (Triumphant Giraffe) RFC [View change log][change-log] |
+| 2014-06-01 | Version 2.0.0-draft (Triumphant Giraffe) RFC       |
 | 2013-08-26 | Version 1.0 (unnamed) released.                    |
 | 2013-06-14 | Version 0.9 (unnamed) released.                    |