Interaction between behaviors

[zimeon]

Original Issue
IIIF/api#1643

Issue
How should clients interpret multiple behaviors (either specified directly or inherited per #13 - an orthogonal issue) that might interact in some way, in order to give a consistent user experience?

Background
Early drafts of Presentation API v3 called out certain cases of possible interaction, such as repeat with and without auto-advance, but left many cases open to interpretation. There was concern that not specifying how clients should interpret combinations would lead to inconsistent user experiences for a resource viewed in different environments.

Solution has two parts

• Introduce a notion of sets of disjoint behaviors, ones that MUST NOT be specified together because they don't make sense (e.g. a Manifest cannot be both paged and continuous). This is testable and a validator can throw errors if violated.
• Accept that we don't know enough to formally specify behaviors for all possible combinations of behaviors. Instead advise implementers to:
  1. Look in the cookbook for non-normative recommendations on how to deal with behavior interactions that may then be updated as experience grows, without needing a new version of the specification.
  2. Add a warning that new rules for how to deal with behavior interactions may be added to the normative specification in minor version updates.

[aisaac]

As an explanation for my not being in favour of this: I think this is beginning to dive too much into things that are not going to be crucial at all to most users, adding complexity and opening the floor to discussions. This will make the spec harder to understand (for implementers) and to maintain (for the editors and the TRC).
I would prefer everything to be in the cookbook. And rely on serious implementers to look at this and not use conflicting behaviours. Or if they do it, that they would have a strong reason to do it (which would then be very interesting, if it ever happens).

[cubap]

I like this perspective from @aisaac , but the best solution may exist somewhere between. Wishing that there is a "less complicated" spec to review may not mean relegation to a cookbook, but may be a suggestion that the layout of the spec be streamlined so that the "behaviors" section can be skipped or skimmed if it isn't important to someone reading the spec as a distance.

[azaroth42]

The implication of rejecting this issue, and #13, is that publishers are conforming when they publish impossible to present combinations of behaviors, and clients are conforming when they do diametrically opposed things in the presence of those combinations. This has led to client developers asking for further clarity as what /should/ be done.

[aisaac]

Note: the interest of developers in this is not reflected in IIIF/api#1643 (the issue currently displayed as the original here) but in IIIF/api#1612

[azaroth42]

Yes, good point! The original question was just about interactions generally, but we split into two to try and be clearer about the types of interaction we needed to work through -- 1643 was created for the disjointness and pairwise interactions within a resource, 1612 used for the inheritance of behaviors across resources.

[jpstroop]

I don't think it would be a breaking change to introduce the concept of disjoint behaviors in a later (minor) version, right? Maybe a callout in the spec acknowledging this concern, that the matrix of possible combinations is too large to cover every case, and that we would prefer to see more use/implementation before adding further recommendations/requirements/constraints is enough for now?

[azaroth42]

I think it would be breaking, as ["a", "not a"] would go from being legal to not being legal.

[aisaac]

I've always been puzzled about how to consider these changes that materialize constraints that have been envisioned at an earlier state. Technically it's a breaking change, but from the perspective of the data publishers who might suffer from it (if ever someone does mess around with behaviours, which I still struggle to see massively happening), it could be advertized as a 'grace period' that has been given to them.

In Europeana we have had a number of changes to cardinality constraints, which were rather positioned as 'quality-related updates'. Of course doing such thing requires that a large part of the community is onboard. But I believe that IIIF community and processes are strong enough for that. Especially if there is a note and/or a recipe cookbook that present the best practice that would eventually be enforced.

[aisaac]

NB: my point above shouldn't be understood as something that I really want to happen. I am still +0 on this issue (and -1 for #13) but if developers massively welcome the additional complexity being in the spec, I will be ok.

[jpstroop]

I think it would be breaking, as ["a", "not a"] would go from being legal to not being legal.

If that's the case (and I see your point) then I think whatever we ultimately decide needs to go into the spec, as opposed to the cookbook, because it's starting to sound normative.

[zimeon]

While the spec gets marginally longer and more complex through the introduction of sets of disjoint behaviors, I think that is far outweighed by the clarity of what behaviors can and cannot be used together.

I agree with @azaroth42 that introducing normative disjointness later would be breaking. The disjoint sets are clear so we can safely do that now, in v3.0, and leave other more subtle complex interaction notes to be worked out in the cookbook (the essence of the two-pronged solution proposed).

[azaroth42]

Issue 16 (Interaction between behaviors)

+1: 20 [awead azaroth42 beaudet cubap emulatingkat gigamorph irv jonhartzler joshuago78 julsraemy jwd markpatton mcwhitaker mikeapp mixterj regisrob scossu tomcrane tpendragon zimeon]
0: 6 [aisaac jbhoward-dublin jtweed kzhr rsinghal sredick]
-1: 0 []

Result: 20 / 26 = 0.77

Super majority is in favor, issue is approved