You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
According to the Readium Audiobook Profile, a RWPM must contain the duration property in the Link objects to conform.
However, the mobile toolkits Publication.conformsTo() API is only checking the media type in the reading order, not the availability of duration, so it's not checking full conformance. The reason for this is that we don't have the info for Zipped Audiobooks.
As a workaround, we could add an Audio/MediaPublicationService which will compute the duration from:
the duration Link object properties for streamed manifests
the resource metadata for Readium Packages and ZAB
Then, the conformsTo() API could use this info to check that the duration is available for all the resources of the reading order.
The text was updated successfully, but these errors were encountered:
In hindsight, I feel like the conformsTo method might have been a mistake. To really check conformance to a profile, we have Publication.metadata.conformsTo. The method (vs the property) has been designed to determine which navigator should be used to render the publication. I don't think that's the responsibility of the shared module. Each navigator should be able to claim which publication it supports, whatever profile it conforms to, if any.
Each navigator should be able to claim which publication it supports, whatever profile it conforms to, if any.
I like this idea, testing a queue of navigator implementations until one handles the publication. In which case, that's fine if we're stricter with the conformsTo() API.
According to the Readium Audiobook Profile, a RWPM must contain the
duration
property in the Link objects to conform.However, the mobile toolkits
Publication.conformsTo()
API is only checking the media type in the reading order, not the availability ofduration
, so it's not checking full conformance. The reason for this is that we don't have the info for Zipped Audiobooks.As a workaround, we could add an
Audio/MediaPublicationService
which will compute theduration
from:duration
Link object properties for streamed manifestsThen, the
conformsTo()
API could use this info to check that the duration is available for all the resources of the reading order.The text was updated successfully, but these errors were encountered: