Re: Manifest/Metadata requirements

A system/process/application that would update an existing PWP.  It might be a publication system – for example, O’Reilly’s system knows about author updates to books, and might choose to push out updates.  Or it might simply be an end user that is creating a new PWP by combining pieces from existing ones (aka remixing or repurposing) using some desktop tool.

Leonard

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

What’s an updating system?

Tzviya Siegman
Information Standards Lead
Wiley
201-748-6884
tsiegman@wiley.com<mailto:tsiegman@wiley.com>

From: Leonard Rosenthol [mailto:lrosenth@adobe.com]
Sent: Tuesday, June 07, 2016 10:51 AM
To: Bill Kasdorf; W3C Digital Publishing IG
Subject: 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<mailto:bkasdorf@apexcovantage.com>>
Date: Tuesday, June 7, 2016 at 10:34 AM
To: Leonard Rosenthol <lrosenth@adobe.com<mailto:lrosenth@adobe.com>>, W3C Digital Publishing IG <public-digipub-ig@w3.org<mailto: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