Image API 3.0

[jpstroop]

• 1.1.1. Remove size full in favor of max

Done: 43fd62d

Per the deprecation warning in the previous version, the value full is no longer allowed for the size parameter, max must be used instead.

See issues IIIF/api#678 and IIIF/api#1369.

• 1.1.2. Changes to upscaling of images to larger than the extracted region

Done: efa6342

Unless prefixed with a caret (^), the value of the size parameter must not result in an image larger than the extracted region, and attempts to do so must generate an error response. Previous versions allowed implementations to optionally and implicitly support scaling up. The sizeAboveFull feature name was also removed. Servers may still support upscaling by indicating that they support the sizeUpscaling feature.

See issues IIIF/api#693, and IIIF/api#1627.

• 1.1.3. Change canonical form of size parameter to w,h

Done: 3c04fa5

Per the deprecation warning and the inconsistency warning about the size parameter in the previous version, the canonical form of the size parameter is now w,h unless the maximum size is requested, in which case the canonical form is now max. This resolves the inconsistency between the server-preferred values in the sizes object, and the canonical form of the size parameter. In order to request preferred sizes, a client should use the width and height values from sizes unmodified to build the w,h size to request. Clients should also use canonical form of the size parameter w,h when constructing tile requests.

See issues IIIF/api#544 and IIIF/api#678.

• 1.2.1. Rename @id to id, @type to type

Done: 86fb7ea

These properties were renamed to enable Javascript developers to use the "dot notation" (image.id) instead of the square-brackets based equivalent needed with the @ character (image['@id']). This follows JSON-LD community best practices established by schema.org, the JSON-LD, Web Annotation and Social Web working groups.

See issue IIIF/api#590.

• 1.2.2. Remove the attribution and logo properties

n/a - Was never implemented

The attribution and logo properties have been removed to better separate concerns between the Image and Presentation APIs. Both properties continue to be available in the Presentation API.

See issue IIIF/api#1787. Approved by trc#12.

• 1.2.3. Rename license to rights, allow only a single value

n/a: Was not implemented. Updated #122

The license property was renamed to rights to accommodate both rights statements and usage licenses. The value is constrained to be a single URI, an array is no longer permitted. The value is further constrained to allow only Creative Commons URIs, RightsStatements.org URIs and URIs registered as extensions. This additional constraint is to allow clients to treat the property as an enumeration rather than free text, and implement URI specific behavior.

See issues IIIF/api#644 and IIIF/api#1479.

• 1.2.4. Require the type property on all resources, with new values

Done: ea17fe0

The type property with a single value is now required on all resources, including content resources and services. This serves several purposes, including facilitating object mapping code libraries, and forcing the serialization to generate a JSON object for the resource, not just a string with the resource's URI. The values for type have been changed to version-specific strings that avoid the namespace structure, for example from iiif:Image in 2.1 to ImageService3 in 3.0. Note that the @type property is used only when referring to object from older specifications such as the Authentication API 1.0.

• 1.2.5. Change the profile property to take one compliance level

Done: f8f05e3

The profile property must have a single value that is a compliance level string. The property value must not be an array as in previous versions, and features supported beyond those specified are instead described in the new extraFeatures property.

See issues IIIF/api#1275, IIIF/api#1373, IIIF/api#1554, and IIIF/api#1013.

• 1.2.6. Change the service property value to an array of objects

n/a: No extra services are implemented.

In version 2.1 the value of the service property could be a single value or an array of objects, the value must now be an array of objects.

See issue IIIF/api#1131.

• 1.2.7. Remove feature names sizeByWhListed and sizeByForcedWh

n/a Was never implemented.

Per the deprecation warning in the previous version, the feature names sizeByWhListed and sizeByForcedWh have been removed. See PR #727.

• 1.2.8. Remove feature name sizeByDistortedWh

Done: fd61bfd

The feature sizeByWhDistorted has no useful meaning separate from sizeByWh and was thus removed.

See issue IIIF/api#879.

• 1.2.9. Use language map pattern for label

n/a: Label not implemented.

In the Presentation API and here, a new pattern has been adopted for all textual values of a JSON object with the language code as the key (or none if the language is not known) and the content as a string within an array as the value. This pattern is much easier to implement and use than the previous @value / @language tuples pattern.

See issues IIIF/api#755 and IIIF/api#1739. Approved by trc#2 and trc#5.

• 1.2.10. Clarify content negotiation expectations

Done: 821364b

Expectations around the implementation of content negotiation were added.

See issue IIIF/api#1685.

• 1.3.1. Require support for region square at level1 and level2 compliance

Done: fe3024c

Support for the region parameter value square, introduced in version 2.1, is now required at level1 and level2 compliance.

See issue IIIF/api#501.

• 1.3.2. No longer require support for pct:x size at level1 compliance

Done: See 9e9a0bf

Support for the pct:x size form is no longer required at level1 compliance. This is consistent with the pct:x,y,w,h for region as both are now level2 features.

See issue IIIF/api#478.

• 2.2. Add partOf and seeAlso linking properties

New: Created #180

Two linking properties also present in the Presentation API were added to the image information. The seeAlso property addresses the use case of providing a link to technical metadata, and the partOf property supports discovery of a containing Manifest.

See issues IIIF/api#1507 and IIIF/api#600.

[jpstroop]

Closed by #179