RE: note on offlinepackage requirements

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

Received on Wednesday, 29 July 2015 17:18:41 UTC