Previewing IIIF - a summary

[stephenwf]

Following from: #19 #55 #12 https://github.com/digirati-co-uk/iiif-manifest-editor/wiki/Preview

Previewing IIIF

In order to preview IIIF, there must be some communication from the Manifest editor to the tool that is previewing. Ideally this would be decentralised, so that a manifest editor does not need to host its own viewers.

level0

This is the baseline level for a viewer. A viewer must accept a Manifest in its URL, and that should be able to be templated.

https://example.org/my-viewer?manifest={manifestUri}

This level of support allows for simply hosting a manifest and passing it to the viewer to preview.

level1

A level1 implementation must accept a IIIF content state in its URL and also a manifest and react to changes to this state, allowing for the viewer to be controlled through basic Manifest / canvas changes.

https://example.org/my-viewer?iiif-content={contentState}

This level of support would allow for some basic contextual information to be retained while reloading and previewing your resource. For example, if you're working on a particular canvas - that canvas will be loaded into the preview.

level2

A level2 implementation must implement both level0 and level1, but additionally must support advertising postMessage capabilities. It may choose to implement some or all of the postMessage options.

• IIIF content state - accepts content state through post-message instead of through a URL
• Reload event - accepts and refetches the current resource when it is accepted
• Manifest JSON data - accepts a manifest as JSON, without it being hosted anywhere

Details of these events TBC.

[tomcrane]

(see also https://github.com/digirati-co-uk/iiif-manifest-editor/wiki/Preview which is mainly level 0 atm, as defined above)