RE: note on offlinepackage requirements

Thanks all.

I’ve put this on our TF wiki [1] with Ivan’s comments as indented text. The Google Doc was intended as a scratch pad anyway.

[1] https://www.w3.org/dpub/IG/wiki/Portable_Package_Requirements



Tzviya Siegman
Digital Book Standards & Capabilities Lead
Wiley
201-748-6884
tsiegman@wiley.com<mailto:tsiegman@wiley.com>

From: Matt Garrish [mailto:matt.garrish@bell.net]
Sent: Monday, August 03, 2015 9:49 AM
To: 'Brady Duga'; Siegman, Tzviya - Hoboken
Cc: 'Ivan Herman'; 'Liam Quin'; 'W3C Digital Publishing IG'
Subject: RE: note on offlinepackage requirements

If you set to allow only comments people will still be able to edit the document, but any changes will be done in suggesting mode so the alterations will be apparent until they're accepted. Not a perfect solution, but one way to limit the damage that can be done.

Matt

From: Brady Duga [mailto:duga@google.com]
Sent: August 3, 2015 9:38 AM
To: Siegman, Tzviya - Hoboken <tsiegman@wiley.com<mailto:tsiegman@wiley.com>>
Cc: Ivan Herman <ivan@w3.org<mailto:ivan@w3.org>>; Liam Quin <liam@w3.org<mailto:liam@w3.org>>; W3C Digital Publishing IG <public-digipub-ig@w3.org<mailto:public-digipub-ig@w3.org>>
Subject: Re: note on offlinepackage requirements

Permissions "Anyone with link can edit" really means that :) And I believe this list is publicly archived, which means there are spiders out there looking for links, email addresses, etc. In the IDPF we solved this by having an associated group to which you must belong to get write access to the document, but that fits better with the structure there since that same group is used for emails.

On Mon, Aug 3, 2015 at 6:12 AM, Siegman, Tzviya - Hoboken <tsiegman@wiley.com<mailto:tsiegman@wiley.com>> wrote:
Neither did I :(

Tzviya Siegman
Digital Book Standards & Capabilities Lead
Wiley
201-748-6884<tel:201-748-6884>
tsiegman@wiley.com<mailto:tsiegman@wiley.com>


-----Original Message-----
From: Ivan Herman [mailto:ivan@w3.org<mailto:ivan@w3.org>]
Sent: Monday, August 03, 2015 9:12 AM
To: Siegman, Tzviya - Hoboken
Cc: Liam Quin; W3C Digital Publishing IG
Subject: Re: note on offlinepackage requirements


> On 03 Aug 2015, at 15:09 , Siegman, Tzviya - Hoboken <tsiegman@wiley.com<mailto:tsiegman@wiley.com>> wrote:
>
> Thank you, Ivan
>
> The document was clearly hacked. I will get this on W3C site before the meeting.

Sigh… I did not realize Google docs are also hacked (we had regular problems with wiki pages and with spam comments on blogs…)

Ivan


> /tzviya
>
> Tzviya Siegman
> Digital Book Standards & Capabilities Lead Wiley
> 201-748-6884<tel:201-748-6884>
> tsiegman@wiley.com<mailto:tsiegman@wiley.com>
>
> -----Original Message-----
> From: Ivan Herman [mailto:ivan@w3.org<mailto:ivan@w3.org>]
> Sent: Saturday, August 01, 2015 9:16 AM
> To: Siegman, Tzviya - Hoboken
> Cc: Liam Quin; W3C Digital Publishing IG
> Subject: Re: note on offlinepackage requirements
>
> I have added some comments/questions to the document.
>
> Ivan
>
>> On 29 Jul 2015, at 19:17 , Siegman, Tzviya - Hoboken <tsiegman@wiley.com<mailto:tsiegman@wiley.com>> wrote:
>>
>> Thanks, Liam
>>
>> Very useful advice. I am working on some revisions to the document [1], and we will discuss this again on Monday.
>>
>> I have now added some information to the introductory section
>> indicating that there are really three states Online Offline (cached)
>> Portable
>>
>> There are several requirements listed that I am on the fence about including because it is not clear to me whether they are packaging requirements per se. Navigation is a perfect example. Navigating using HTML and ARIA is not about a package format; rather this is content with rich meaning that (can) inform behavior. The information Liam added about Reachability is about packaging.
>>
>> I am also working on prioritizing these issues, so you may see some items move around.
>>
>> Please share your ideas on the document itself or on this list.
>>
>> [1]
>> https://docs.google.com/document/d/1ShvCn3roYENFMAqYhFL169nTeov1f-1OL

>> 6
>> rsJa6nDZk/edit?usp=sharing
>>
>> Tzviya Siegman
>> Digital Book Standards & Capabilities Lead Wiley
>> 201-748-6884<tel:201-748-6884>
>> tsiegman@wiley.com<mailto:tsiegman@wiley.com>
>>
>> -----Original Message-----
>> From: liam [mailto:liam@w3.org<mailto:liam@w3.org>]
>> Sent: Monday, July 27, 2015 2:21 PM
>> To: 'W3C Digital Publishing IG'
>> Subject: note on offlinepackage requirements
>>
>> Thanks for writing a clear and helpful document. I did notice a couple of places where more focus might be needed, so maybe these notes will help with that.
>>
>> I suggest reviewing this with the concept of actors in mind - that is, who will do what to whom...
>>
>> (no, it's polite, it's OK)
>>
>> Example - under Navigation & acdess to content, I read, "It must be possible to accesses the content, including disjoint elements."
>>
>> Possible for whom, under what circumstances? The context:
>> [[
>> Navigation & access to content
>>
>> It must be possible to accesses the content, including disjoint elements. This should be achievable with simple navigational constructs, such as the HTML <nav> structure. It must also be possible to access the whole package as well as components of the package.
>> ]]
>>
>> So does this mean that the contents must be accessible (in the WAI and ARIA sense)?
>> Or that a user reading an ebook must be able to reach all of the chapters from the table of contents, that there must not be any unreachable chapters?
>> Or that software reading a package after downloading it must be able
>> to read data starting at any desired <nav> element? (the nav element
>> sounds like part of a solution, not a requirement, but I'm not
>> certain)
>>
>> Since these are requirements for a packaging format I _think_ what is
>> meant is,
>>
>> [[
>> Reachability
>>
>> The package format must define a format for a manifest in such a way that consuming software does not need to process the full archive in order to determine the nature and size of all components of the archive.
>> ]]
>>
>> Under Streambility, "Once the package is in its offline state" - what
>> does that mean exactly? "reach out... to additional information do
>> you mean that HTML included in the package must be allowed to contain
>> links to the Web? Surely the video would be included in the package
>> if it is essential? Is the requirement here,
>>
>> [[
>> Direct (random) Access
>>
>> It must be possible for an HTTP client to fetch components of a package in any order, or to fetch multiple components at the same time, without having read the entire package - for example by making specific HTTP requests based on an initial table of contents at the start of the package.
>> ]]
>>
>> I find it easier to write documents like this if I start out by writing "The package format must" at the start of each section, even if those words don't remain in the final version. It may also help to identify at the start exactly who or what is constrained by each MUST or MAY or MUST NOT [1] as then that can be reviewed later.
>>
>> Or to put it another way, ask who would do what differently in order to ensure that the requirements are met by an actual implementation.
>>
>> Hope this helps,
>>
>> Liam
>>
>> [1] there MUST NOT be use of "may not" in standards :-) because of the ambiguity, "you may not go outside today." "It may or may not rain today"
>>
>> --
>> Liam Quin, W3C
>> XML Activity Lead;
>> Digital publishing; HTML Accessibility
>>
>>
>
>
> ----
> Ivan Herman, W3C
> Digital Publishing Activity Lead
> Home: http://www.w3.org/People/Ivan/

> mobile: +31-641044153<tel:%2B31-641044153>
> ORCID ID: http://orcid.org/0000-0003-0782-2704

>
>
>
>


----
Ivan Herman, W3C
Digital Publishing Activity Lead
Home: http://www.w3.org/People/Ivan/

mobile: +31-641044153<tel:%2B31-641044153>
ORCID ID: http://orcid.org/0000-0003-0782-2704