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

>RS vs browser
>
Then let’s use the term from the HTML spec – User Agent (UA).  That’s a perfectly fine, generic term.


> 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.
>
As Vlad and I have discussed in these threads before, the font licensing model is changing every day due to the changes in technology.  However, in this case, licenses aren’t about where things are stored as much as how they are used.  For example, if I license a font for use in a specific publication (or in web terms, a specific site), then as long as it is only used to render the content from that site/publication – it doesn’t matter if that rendering is taking place online or offline.   So its really up to the RS to ensure that it doesn’t use that font for some other publication.  That same concept also applies to things such as “stock photography” which can sometimes be licensed for a specific publication or site.  So the “scope” of the license would be important to convey in the “manifest” and then respected by the RS, where relevant.


When I referred to “owned” by the author – I put it in quotes such that they have a license to use it in the publication.   Going back to one of our early examples – the Mona Lisa.  I probably don’t have the rights (under normal conditions) to include an image of it in my publication but I can certainly link to the online version.  Now, that picture may be essential to my publication (if its all about the Mona Lisa) but then it would be my responsibility as the author to obtain the appropriate rights to ensure that I could do that.  And if I can’t then I shouldn't be marking it as “essential”.  BUT if I do – then the problems are my as author NOT the RS/UA

Leonard

From: Ivan Herman <ivan@w3.org>
Date: Thursday, June 9, 2016 at 12:55 PM
To: Leonard Rosenthol <lrosenth@adobe.com>
Cc: W3C Digital Publishing IG <public-digipub-ig@w3.org>, Heather Flanagan <rse@rfc-editor.org>, Romain Deltour <rdeltour@gmail.com>
Subject: Re: use case documents, manifests, latest lists...

Hi Leonard,

On 8 Jun 2016, at 17:32, Leonard Rosenthol <lrosenth@adobe.com<mailto: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<mailto:ivan@w3.org>>
Date: Wednesday, June 8, 2016 at 12:26 PM
To: W3C Digital Publishing IG <public-digipub-ig@w3.org<mailto:public-digipub-ig@w3.org>>
Cc: Heather Flanagan <rse@rfc-editor.org<mailto:rse@rfc-editor.org>>, Romain Deltour <rdeltour@gmail.com<mailto:rdeltour@gmail.com>>
Subject: use case documents, manifests, latest lists...
Resent-From: <public-digipub-ig@w3.org<mailto: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


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/

mobile: +31-641044153
ORCID ID: 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