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> wrote:

> Neither did I :(
>
> Tzviya Siegman
> Digital Book Standards & Capabilities Lead
> Wiley
> 201-748-6884
> tsiegman@wiley.com
>
>
> -----Original Message-----
> From: Ivan Herman [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>
> 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
> > tsiegman@wiley.com
> >
> > -----Original Message-----
> > From: Ivan Herman [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> 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
> >> 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
> >
> >
> >
> >
>
>
> ----
> 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
>
>
>
>
>