Re: *Possible* additional use cases

> On 26 Oct 2016, at 14:12, Leonard Rosenthol <lrosenth@adobe.com> wrote:
> 
> Ivan – I support adding the two new lawyer use cases.  They are worth including.
> 
> However, I don’t see any benefit to the change to 2.3 with that new example.  The ones there now speak just fine, IMO, to the requirement.

I found the one in the mail below (coming from the issue discussion, in fact) more concise and it also make explicit that, in some cases, a PWP is exchanged via physical media…

But let the IG make the final decision. For the time being I kept both in the working version, it is at:

https://rawgit.com/w3c/dpub-pwp-ucr/reorg-3rd-round/index.html#pwp

Ivan


> 
> Leonard
> 
> From: Ivan Herman <ivan@w3.org <mailto:ivan@w3.org>>
> Date: Monday, October 24, 2016 at 6:24 AM
> To: W3C Digital Publishing IG <public-digipub-ig@w3.org <mailto:public-digipub-ig@w3.org>>
> Subject: Re: *Possible* additional use cases
> Resent-From: <public-digipub-ig@w3.org <mailto:public-digipub-ig@w3.org>>
> Resent-Date: Mon, 24 Oct 2016 10:25:12 +0000
> 
> Dear all,
> 
> I started this thread a while ago, and we agreed that we would come back to this once the new draft version of the UCR is around. Now that Heather has done that, let me revisit this (also considering the discussions on the thread).
> 
> 
>> On 13 Oct 2016, at 13:56, Ivan Herman <ivan@w3.org <mailto:ivan@w3.org>> wrote:
>> 
>> Dear all,
>> 
>> as we said on our last call, there may be some new use cases that popped up during the github discussions of the last month. I went through the open issues to see what were raised there. I haven't yet compare it to the latest version of the UCR to check whether these are really new requirements (at first glance they look like it) also because that document is still kind of a moving target. However, I did not want to unnecessarily pollute the github repo either; so I copy the 4 use cases I extracted in the mail below for first sanity check. I will put as explicit issues the ones that we agree upon as o.k. (any linguistic/grammatical changes are welcome); we can then take care of them when both Leonard and Heather declare victory in the big set of changes.
>> 
>> With that, here they are:
>> 
>> Req XXX: the user agent should be able to verify that the (P)WP has not been tampered with at delivery.
>> 
>> The author/publisher should be able to provide information (cryptographic hash, blockchain entry, etc.) usable by a user agent to check the content is genuine and has not been tampered with.
>> 
>> Use Case:
>> 
>> - LegalPublisher Ltd. regularly publishes the official legal texts and regulation as decided by the local government. Michael, who is a lawyer, has access to these documents via his law firm, and uses them for his cases; to do so, he must be 100% sure that the publication he accesses faithfully reproduces the latest governmental decisions.
>> 
>> (Related to, and mentioned in issue #110)
>> 
> 
> I believe this is not covered by the current draft. One of the options on the table (to be discussed later) is to separate the security issues and turn them into a new top level section, relevant to both packaged and not.
> 
> I would propose to add it to that section
> 
> 
>> 
>> ----
>> 
>> Req XXX: the user agent should be able to verify the exact origin of the publication.
>> 
>> The author/publisher should be able to provide information (signature, identifier, etc) that can be served, and checked, as a unique identifier of the origin.
>> 
>> Use Case:
>> 
>> - Michael, who is a lawyer, and uses the publications of LegalPublisher Ltd., must be 100% sure that the publication he uses for his case has indeed been published by LegalPublisher Ltd., and not by a possible third party.
>> 
>> (Related to, and mentioned in issue #110)
>> 
> 
> Again, I believe this is not covered by the draft either. Subsequent discussions on the thread suggestec that (a) it may be difficult to achieve it and (b) this is really bound to the packaged world. If (b) is indeed true (I am not 100% sure), that should not be a problem because we have now separated the packaged world altogether. On (a), whether it can achieved or not is a different issue: if it is a genuine use case/requirement then we should document it, a subsequent WG may decide not to fulfill it for very good technical reasons.
> 
> I propose to add it to the security section.
> 
> 
> 
>> ----
>> 
>> Req XXX: Any genuine user agent must be able to provide a usable view of a Web Publication albeit, possibly, without the full functionality that a WP provides
>> 
>> A full-blown, WP aware user agent may use a number of information incorporated, for example, in the manifest of a Web Publication (e.g., separate table of content control, visual representation of the publication's metadata information like ISBN-s or DOI-s, etc.). However, not all user agents are necessarily WP aware. Nevertheless, the structure of a Web Publication should provide a graceful degradation for these cases and not make the presentation of the publication impossible.
>> 
>> - Ossi has access to a technical Web Publication on the Web. However, he is working from behind a corporate firewall, which does not allow him to install the necessary browser extensions to manage all features of a Web Publication. Nevertheless, even without this extension, he is able to get to the essential information of the document which allows him to do his work.
>> 
>> (Related, albeit loosely, to issue #110)
> 
> This one is indeed a bit loose (Garth called in "noble":-), and could be considered as a consequence of general Web principles that aim at providing proper fallbacks.  Leonard also said: "I removed and/or rewrote them as Marcos, Mike and others made it clear that we should NOT be putting anything on User Agents".
> 
> To be honest, I am not sure. Maybe this is a kind of a 'design principle' rather than anything else, ie, any design we do should be such that a graceful fallback would be possible; putting it this way makes it more relevant as part of a charter rather than a use case in this document. So we may want to drop it, but keep it in our minds...
> 
> 
>> 
>> ----
>> 
>> Req XXX: there is need to send a Web Publication from A to B over different media, not only Web protocols.
>> 
>> Use Case:
>> 
>> - Dave is reading Moby Dick on his tablet (at home with network connectivity). He then jumps on a plane with his good friend Tzviya. After having finished reading the book, he wants to lend it to Tzviya, so that she can start reading on her own tablet. They are both offline, but can exchange data with SD cards or Bluetooth.
>> 
>> (Related, albeit loosely, to issue #113)
> 
> 
> This is very close to the section on 'distribution' (section 3.2 in the Oct. 23 version of the UCR document), and duplicate some of the use cases there. I wonder, however, if this use case is not easier to grasp than the current third Use Case ("Andreas is working…"). Also the formulation of the requirement "It should be possible to create and distribute a PWP as a uniquely identified single resource unit." may be a bit more vague. (Also, one of my proposal in a separate mail is to move the 'single' unit section, preceding this one, to the WP part.)
> 
> I propose to change section 2.3 as:
> 
> - reformulate the requirement itself as "It should be possible to create and distribute a Web Publication as a single unit over different media, not only Web Protocols"
> - replace the third use case with the one on Dave & Tzviya
> 
> Cheers
> 
> Ivan
> 
> 
> ----
> Ivan Herman, W3C
> Digital Publishing Technical 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 Technical Lead
Home: http://www.w3.org/People/Ivan/
mobile: +31-641044153
ORCID ID: http://orcid.org/0000-0003-0782-2704