Presentation 3 spec should be accompanied by processing algorithm(s)

[tomcrane]

The logic a client should follow when presenting a canvas might be difficult to infer from the spec, especially for potentially very complex scenes possible in Presentation 3 (e.g., #1191).

Many people find a pseudocode algorithm a good way to understand and learn the spec, and build implementations.

We should have one for Presentation 3, especially for laying out a Canvas.

Comparison - the JSON-LD spec has many processing algorithms: https://www.w3.org/TR/json-ld-api/

[azaroth42]

Thumbnail selection would be another good algorithm, and possibly easier to get the ball rolling with.

[tomcrane]

I have already started rolling that ball for thumbnails.

[azaroth42]

@workergnome Interested in your thoughts on specifying algorithms. Does this help developers or simply tell them what to do, rather than giving them a problem to solve (the interesting part of developing software, IMO)?

Context -- in an unrelated discussion, we opined that the IIIF documentation is most useful for publishers of the Presentation API and is much harder to use for consumers of it. We wondered whether there are changes that can be made in the spec to improve that, whether the cookbook would be sufficient if it has both publisher and consumer recipes for the same feature, or whether a second "client developer handbook" would be better.

[workergnome]

Problem solving is only fun if there's not a 'correct' answer. Either there's an algorithm, and thus it should be documented, or there's not a 'correct' way to do this, which means that there should be no requirements at all. My experience, having implemented a IIIF publishing library, and having spent several insomniac evenings thinking about implementing a client library, is that it's very, very hard to make sure that what you're doing follows the spec, because the spec is very complex, and many things can interact.

The usual solution to this is to provide a reference library that implements the algorithm, but that might be too large of a task for IIIF to tackle?

[sdellis]

Manifesto that is an extremely useful reference library for client-side implementations (if that's what you mean by "reference library," @workergnome). I would hope the community could help contribute implementations of any of the proposed algorithms in Manifesto.

I'm wary of labeling any answer to a design problem as "correct". "Conventional" may be more appropriate term for an accepted solution to a common problem. Context will dictate the best solution to a given presentation problem, which may require unconventional approaches.

[zimeon]

In Ed's call: core processing algorithms document should go at /api/presentation/3.0/processing/ but there may well be an additional annex document as well

[azaroth42]

Tom to do thumbnail as a case study.

[tomcrane]

IIIF AV Meeting suggestions:

• Canvas on Canvas
• Language selection - does this move out of the spec? - no
• Ranges, manifest.items, thumbnail strips, behavior:sequence
• Processing Collections where items is a mixture of Collections and Manifests

English pseudocode can be difficult to write, where maintaining state is required. Some may find more value in a reference implementation (as mentioned above)

Pseudocode may be easier to maintain

[azaroth42]

If we're doing algorithms separately, should it be like cookbook and instead be implementation notes for all the specs? (And I think the answer is yes)

[tomcrane]

Yes.

[azaroth42]

Should this be moved to IIIF/cookbook-recipes and split into separate algorithms?