- From: Bill Kasdorf <bkasdorf@apexcovantage.com>
- Date: Tue, 7 Jun 2016 14:34:06 +0000
- To: Leonard Rosenthol <lrosenth@adobe.com>, W3C Digital Publishing IG <public-digipub-ig@w3.org>
- Message-ID: <CY1PR0601MB1422FA873687EFDED43CB665DF5D0@CY1PR0601MB1422.namprd06.prod.outlook.>
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
Received on Tuesday, 7 June 2016 14:34:43 UTC