Question about enforcement of dcterms:modified metadata element

[nleme]

Hi,

I'm taking a look at the code for Readium SDK, and I noticed the following piece of code in the file package.cpp, lines 539-540:

    if ( !foundModDate )
        HandleError(EPUBError::OPFMissingModificationDateMetadata);

Basically, what that does is to make mandatory that the OPF for a given ePub must have the "dcterms:modified" metadata element. Because of that, if a given ePub does not have that metadata element, the Readium SDK will not be able to open that ePub.

I'm not aware of the discussions around that definition on the spec, however, is that metadata element that critical? I think that maybe the standard could be more forgiving around this specific piece of data.

[AlanQuatermain]

The ePub 3 spec says that property is required, as it's used in the generation of the publication's unique ID. It wasn't required for earlier versions of the spec though.

Sent from my iPhone

On Jul 11, 2013, at 6:02 PM, Nelson Leme notifications@github.com wrote:

Hi,

I'm taking a look at the code for Readium SDK, and I noticed the following piece of code in the file package.cpp, lines 539-540:

if ( !foundModDate )
    HandleError(EPUBError::OPFMissingModificationDateMetadata);

Basically, what that does is to make mandatory that the OPF for a given ePub must have the "dcterms:modified" metadata element. Because of that, if a given ePub does not have that metadata element, the Readium SDK will not be able to open that ePub.

I'm not aware of the discussions around that definition on the spec, however, is that metadata element that critical? I think that maybe the standard could be more forgiving around this specific piece of data.

�
Reply to this email directly or view it on GitHub.

[danielweck]

Just out of interest: can the actual error handler implementation behind "HandleError" be overridden / specified on the client side of the API, so that the Readium SDK can potentially be used in a context different than a reading system app? (e.g. authoring tool => report error / warning, but do not emit a fatal error)
_daniel

[AlanQuatermain]

Yes, the function called by the API here actually calls a user-specified error handler. That makes the decision on whether to throw an exception or not. Probably it could return an enumerated constant instead: throw exception, fail, or ignore.

Sent from my iPhone

On Jul 11, 2013, at 6:13 PM, danielweck notifications@github.com wrote:

Just out of interest: can the actual error handler implementation behind "HandleError" be overridden / specified on the client side of the API, so that the Readium SDK can potentially be used in a context different than a reading system app? (e.g. authoring tool => report error / warning, but do not emit a fatal error)
_daniel

�
Reply to this email directly or view it on GitHub.

[rkwright]

This is truly ancient and the question posed by Nelson seems to have been answered. Closing.

[danielweck]

Note that this issue is now discussed here: readium/SDKLauncher-Android#33

[danielweck]

Note that cancellable warning messages (popup dialogs) have been implemented in iOS, OSX and Android launchers as "error handlers" (as per the SDK terminology):
readium/SDKLauncher-iOS#45
readium/SDKLauncher-OSX#33
readium/SDKLauncher-Android#33
However, this still leaves the issue of discriminating EPUB 2 vs 3 when detecting invalidity problems (should the hard-coded repository of error types include additional EPUB version info?) See new issue: #133