Re: use case documents, manifests, latest lists...

Hi Leonard,

> On 8 Jun 2016, at 17:32, Leonard Rosenthol <lrosenth@adobe.com> wrote:
> 
> I’m going to skip over the questions (all good ones that need answers) and pick on your examples:
> 
> Alice reads an art catalogue publication on line, which is typeset with a particular type of font to increase the visual quality of the publication. Alice wants to be able to enjoy the catalogue offline (eg, on a plane), so she instructs her browser to make this possible. However, to do so, her browser (reading system) should ensure that the special font has the right licensing term to be installed on Alice's machine (as opposed to be just displayed when rendered).
> 
> Requirement:
>                 - 1. the information on the licensing terms of the publication resources must be available to the reading system
> 
> A bunch of things here:
> -          Let’s not talk about browsers, let’s focus on the generic “reading system” (or RS for short)

That is fine. That being said: I know that the term 'Reading System' sounds extremely weird for hard core Web guys (I had to explain that many times to my W3C colleagues). Ie, I am not 100% what the best term is. But let us discuss that another day, it is not that important.

> -          It is NOT the responsibility of the RS to address licensing.  It is the responsibility of the authoring tool(s)
> -          Fonts used for rendering content are NEVER installed into the OS – they are used strictly by the RS (because in most cases they aren’t in a form that is consumable by the OS)
> 

The font example may not be the best (also reading Vlad's mail). However… I do not think I agree that this feature is exclusively the responsibility of the authoring tool. While this may well be true for publications like EPUB, this situation is different: the question that does arise is whether a particular license, while it makes it possible to display the content in a browser in an, essentially transient state, it would not allow it to store it in a local cache or anything that makes a copy of it on my local file system. That means that, in the PWP world, we get to a PWP that is renderable in in an online state (eg, in a browser), it is _not_ renderable in an offline state.

It may be possible that this is the author's responsibility insofar as the author has to specify explicitly to the RS that it should not (is not allowed) to use this PWP in an offline state. That may be an alternative (and maybe more general) information for what I wrote. But I believe that _something_ should be said here, although I admit I do not have a good example for a specific licensing case. Maybe somebody in the group has a good example?

> 
> On example #2, I like it!  One minor comment on the requirement:
>                 - 1. the list of all _essential_ constituent resources must be available to the reading system
> 
> The problem here is that it’s only about resources that are “owned” by the author/publisher of the PWP itself.  Having the various images and CSS that were authored as part of the content as essential makes sense – but what you don’t want (IMO) is someone marking parts of Wikipedia (as used in your example) as essential!    We need to find a good wording for this.

True. Any ideas?

But we also have the perennial example of the font: in some cases, fonts are not essential, ie, an offline state can ignore it, whereas, in other cases, they are essential and offline state should include it. Ie, the list of _essential_ may not be the same as the resources owned by the author.

Actually, that means that the requirement is to be cut into two

 1. the list of all constituent resources
 2. the list of all _essential_ resources

These two sets of information must be available independently imho.

Ivan

> 
> 
> Leonard
> 
> From: Ivan Herman <ivan@w3.org>
> Date: Wednesday, June 8, 2016 at 12:26 PM
> To: W3C Digital Publishing IG <public-digipub-ig@w3.org>
> Cc: Heather Flanagan <rse@rfc-editor.org>, Romain Deltour <rdeltour@gmail.com>
> Subject: use case documents, manifests, latest lists...
> Resent-From: <public-digipub-ig@w3.org>
> Resent-Date: Wed, 8 Jun 2016 10:27:07 +0000
> 
> Dear all,
> 
> we had a really good discussion last Monday, and I was just wondering how to take it further.
> 
> Heather was quick enough to include the list we compiled at the of the meeting into the UCR draft:
> 
> https://w3c.github.io/dpub-pwp-ucr/#manifests-metadata <https://w3c.github.io/dpub-pwp-ucr/#manifests-metadata>
> 
> I was wondering hot to take it from here. I believe what we should do, for each of those entries, to have one or more use cases (simple they may be) that show why those entries are necessary. Editorially, this means collecting the various requirements attached to the use cases. As examples, I picked up 3 of those items and came up with two simple use cases; see below. If we think that is the right way to go, then maybe each of you who participated at the discussion (or others!) should come up with a short text to cover your favourite item on the list; the editors can then combine them into the document. Note that the manifest, at least in my mind, is in a very abstract sense, ie, (at least in my view): we are talking about all the information that a reading system needs to render/process/etc the publication content. Whether these information items should be mapped onto a single JSON file, or several files depending on the content, etc, is the next step.
> 
> Heather & Co. should tell us what the best way is to submit these. I am fine creating a PR on github with this, or just sending them by email, or anything else…
> 
> So here are my two entries for a start:
> 
> [[[
> 
> Alice reads an art catalogue publication on line, which is typeset with a particular type of font to increase the visual quality of the publication. Alice wants to be able to enjoy the catalogue offline (eg, on a plane), so she instructs her browser to make this possible. However, to do so, her browser (reading system) should ensure that the special font has the right licensing term to be installed on Alice's machine (as opposed to be just displayed when rendered).
> 
> Requirement:
>             - 1. the information on the licensing terms of the publication resources must be available to the reading system
> 
> ------
> Dave wants to read a publication that consists of a several chapters, and includes lots of illustrations. Dave also wants to be able to read that content offline.
> 
> The publisher's production workflow is such that each chapter is provided as a separate HTML file; each HTML file links to a number of auxiliary files like CSS or data files, and the illustrations are also provided through separate high resolution images. The HTML files may also include links to other Web resources, which do not form an essential part of the publication, though (e.g., a link to a Wikipedia page describing the subject of the publication); Dave is fine if that resource is not necessarily available while offline
> 
> Requirements:
>             - 1. the list of all _essential_ constituent resources must be available to the reading system
>             - 2. the reading system must have the information on the reading order of the different chapters (including the starting point)
> 
> ]]]
> 
> WDYT?
> 
> Ivan
> 
> ----
> Ivan Herman, W3C
> Digital Publishing Lead
> Home: http://www.w3.org/People/Ivan/ <http://www.w3.org/People/Ivan/>
> mobile: +31-641044153
> ORCID ID: http://orcid.org/0000-0003-0782-2704 <http://orcid.org/0000-0003-0782-2704>
> 
> 
> 


----
Ivan Herman, W3C
Digital Publishing Lead
Home: http://www.w3.org/People/Ivan/
mobile: +31-641044153
ORCID ID: http://orcid.org/0000-0003-0782-2704