Re: Manifest/Metadata requirements

I agree that in the best of all possible worlds, the updating system would update the manifest/metadata – however, in the real world that simply doesn’t happen reliably.  As such, reading systems can’t make assumptions and end up ignoring that type of info.

Leonard

From: Bill Kasdorf <bkasdorf@apexcovantage.com>
Date: Tuesday, June 7, 2016 at 10:34 AM
To: Leonard Rosenthol <lrosenth@adobe.com>, W3C Digital Publishing IG <public-digipub-ig@w3.org>
Subject: RE: Manifest/Metadata requirements

Re item 2, I believe we had a use case along the lines of "As a reading system, I need to know that the manifest accurately and completely reflects the current version of the publication." So if you add such a chapter, you also have to update the manifest accordingly.

Agreed with item 1. I probably should have spoken up yesterday but I didn't want to interrupt the momentum we were on. I think clearly cover image can't be a requirement. Title, though, arguably could be: no matter what the nature of the publication is, it could be argued that a reading system needs some way to identify it to a user. That's of course veering into identifier land, so some wordsmithing to get at the issue of "designed for human readability" or something like that might be appropriate.

—Bill K

From: Leonard Rosenthol [mailto:lrosenth@adobe.com]
Sent: Tuesday, June 07, 2016 8:08 AM
To: W3C Digital Publishing IG
Subject: Manifest/Metadata requirements

Sorry I missed the call yesterday, but in reviewing the minutes on the various use cases, I see two of them that I would like to pick out for further discussions.

1 - As a reading system, I need to know the title and cover image to display the publication on a shelf without downloading all it's content.

In the case of a formal publication – such as a book or magazine – this certainly makes sense.  But as we consider the various informal use cases for PWPs, then such things wouldn’t be present.  So having a place for these things, should they exist, makes sense.  But we need to ensure that they aren’t requirements.


2 - As a reading system, I need to know if I need additional processing instructions, such as with MathML.

This is an example of a general category of things that I class as “the dangers of duplicated data”.

Anytime you have a “feature list” of a document/publication, you run the risk that it will not be properly maintained to match the actual content. What happens if the original version of a publication doesn’t use MathML but a chapter is added later on that contains it but the manifest isn’t updated?   A Reading System (in order to function properly) has to assume that the manifest’s list is wrong – and if it’s wrong, then why bother having it at all.

I would strongly recommend that we not go down this path.


Leonard