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 Monday, 27 July 2015 18:21:08 UTC