Open llemeurfr opened 3 months ago
Since we already have a dedicated media type, I'm not entirely convinced that a new rel
is needed as well.
We can use related
as the rel
value.
@danielweck may chime in here, as we discussed the topic yesterday. The proposal of merging media overlays and guided navigation may be a problem because when a reading system sees such a link in a manifest, it has no clue about the kind of processing it has to initialise.
@llemeurfr I don't see that as much of a threat.
Right now, the only thing you can encounter in an EPUB would be Media Overlays as Guided Navigation (technically you could also encounter region-based navigation, but we both know that there is absolutely zero support for that in the wild). Even if at some point we start encountering authored Guided Navigation Documents in EPUB files, we could further differentiate the two of them using:
rel
values (we could easily roll out a dedicated value for MO)If you're really worried about that, we can preemptively decide what the rel
value should be and implement this right away (starting with the Go toolkit).
We could use the URL of their specifications for that:
Let's adapt an example from EPUB 3.3 to see how this would look like with RWPM:
"readingOrder": [
{
"href": "chapter1.xhtml",
"type": "application/xhtml+xml",
"alternate": [
{
"href": "guided-chapter1.json",
"type": "application/guided-navigation+json",
"rel": "https://www.w3.org/TR/SMIL3/"
}
]
}
]
In https://github.com/readium/guided-navigation?tab=readme-ov-file#22-publication-level the relation between the webpub manifest and the guided navigation structure is "alternate". Semantically this is not the case. I propose a new rel value = "guided-navigation" (or guidedNavitation? I don't remember what is the standardized syntax)