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> 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-1OL6rsJa6nDZk/edit?usp=sharing
> 
> Tzviya Siegman
> Digital Book Standards & Capabilities Lead
> Wiley
> 201-748-6884
> tsiegman@wiley.com
> 
> -----Original Message-----
> From: liam [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
ORCID ID: http://orcid.org/0000-0003-0782-2704