repeated structural relations

[mattgarrish]

We don't restrict the use of structural relations (cover, contents and pagelist) to a single resource, only that they not occur in both the reading order and resource list.

This seems like an oversight, but if multiple are listed we should still make explicit that first found wins (and validate this).

[iherman]

Alas! +1 to

This seems like an oversight, but if multiple are listed we should still make explicit that first found wins (and validate this).

Alas!, because it is an extra complication on the algorithm:-(

[mattgarrish]

Actually, validating the toc and pagelist is quite easy (extend reading order with resource list and walk over each entry), but the cover is proving a bit of a nightmare, at least thinking about it practically.

To be more specific, though, we say that multiple covers are allowed provided they differ on at least one property. Checking each one is unique is going to get interesting. The only property we define that really could be looked at is encodingFormat, but it's kind of useless for the suggested reasons for allowing multiple covers. The spec cites uses such as height, width and rel (?), but we don't have properties for height and width and I don't know what different rel value would help.

We need media queries to make multiple covers useful, and we don't have them by default.

It also feels like if we're going to allow mutliple covers, we should also restrict the rel to one resource and use alternate to list the other options. We defined covers long before alternate came around, unfortunately, but this is kind of a perfect case for it.

At any rate, I'm going to open a PR in a second that strictly interprets the spec as it is right now, but I think we should modify cover alternates and I'm not sure exactly what we do about uniqueness. We can get away without being specific in the algorithm, but it feels underspecified.

[mattgarrish]

Is there a way to have LinkedResource extend MediaObject through the context so that its properties are easily available without having to declare a type?

That would at least get us some useful properties for differentiating covers.

[iherman]

Is there a way to have LinkedResource extend MediaObject through the context so that its properties are easily available without having to declare a type?

"subtyping", in terms of RDF, is doable, but this is not something schema.org does, afaik; I do not think they formally do anything of the sort.

What is possible is to say that a cover page has two types, ie, it mixes in a media object. But that latter is an object with a large number of properties (it is also a creative work), ie, that would not help us too much.

On the other hand, your usage of alternate sounds like a perfect fit. If a linked resource is an alternate of a cover then... it is an alternate for the cover:-). Maybe the only change we may want to have is to claim that alternate is order sensitive after all, which gives a decreasing priority of alternates (eg, from high- to low-resolution images).

[mattgarrish]

If a linked resource is an alternate of a cover then... it is an alternate for the cover:-).

Ya, I update the spec and then realized that but had to go out so didn't have time to fix. I just pushed an update that explicitly says to use alternate for alternatives (i.e., only one instance of the relation is allowed).

Maybe the only change we may want to have is to claim that alternate is order sensitive after all

This is still the tricky part, as there are so many reasons why you might have alternatives. It could be dimensions; it could be resolution; it could be colour/bw. And then you have audio alternatives, etc., etc.

I took out the requirement that alternatives must differ on one property, as that is vague at best (can they differ on url ,name, description, etc.). But I think this gets back to the problem of selecting alternatives I raised in #133. We don't have either a terribly clear or robust way to specify alternatives (which isn't always a bad thing given the complexity of media queries) or a defined process for selecting them, so it'll be hard for an author to figure out what to specify or for a user agent developer to know what to look for.

[iherman]

This is still the tricky part, as there are so many reasons why you might have alternatives. It could be dimensions; it could be resolution; it could be colour/bw. And then you have audio alternatives, etc., etc.

Clearly we do have here a case when respecting order is useful. The real question is: is there any example where order is harmful? Because that is not the case, we can set the order and that gives a useful hint for the choice of an alternative (if there is a need for it).

[mattgarrish]

Clearly we do have here a case when respecting order is useful.

I'm not sure that's the case. The user agent has to pick whichever resource it can consume based on its capabilities and those of the user's device. If there happens to be more than one resource it can use, I'm not sure we need to wade into dictating authored order as the determining factor. Better to let the UA devs determine their own ordering preferences.

It's more important that the UA have enough useful information to determine why there are alternatives and what cases they're intended for than to worry about authored order.

[iherman]

The user agent has to pick whichever resource it can consume based on its capabilities and those of the user's device. If there happens to be more than one resource it can use, I'm not sure we need to wade into dictating authored order as the determining factor. Better to let the UA devs determine their own ordering preferences.

makes sense.