W3C home > Mailing lists > Public > public-digipub-ig@w3.org > September 2015

Re: [Glossary] Portable Digital Document's states

From: Brady Duga <duga@google.com>
Date: Mon, 14 Sep 2015 06:43:43 -0700
Message-ID: <CAH_p_eWvAiYDva4NR4fZjM2HZVrC602weW2NK22rjVS7r46Dhg@mail.gmail.com>
To: Ivan Herman <ivan@w3.org>
Cc: W3C Digital Publishing IG <public-digipub-ig@w3.org>, Ralph Swick <swick@w3.org>
Local and remote instead of packed and unpacked? The use of "one unit" is
odd, since presumably you could have a PDD that is in several files, spread
across multiple folders. What is the unit it was packed into? Also, these
are not necessarily disjoint - parts of a PDD could be remote while other
parts are cached. Maybe just clarify that any components of a PDD in a
cache are considered remote? Makes sense, since browser caches tend to be
transient.

As for the term User Agent, EPUB intentionally uses Reading Systems to
avoid confusion with a browser UA. A Reading System uses composition
(has-a) instead of inheritance (is-a) as the relationship to a UA. It may
not be quite technically correct, but it makes clear that a RS may be more
than a local browser (it includes any polyfills, server components, etc).

On Mon, Sep 14, 2015 at 4:15 AM, Ivan Herman <ivan@w3.org> wrote:

> Hi all,
>
> Trying to move on to some other terms that we have to agree upon: states.
> Maybe this is less controversial.
>
> As a reminder: the "Requirement for Web Publication and Packaging"[1]
> currently defines the following states and their characterization:
>
> • Online state (i.e., a collection of documents on the Web that can be
> considered as a logical unit, a "Web Publication")
> • Cached state (i.e., a collection of documents in the reading engine,
> local system, etc., that can be considered as a logical unit and which is
> mostly indistinguishable from the online state)
> • Portable state (i.e., an package, ie, a collections of documents packed
> into one unit for, e.g., a file system, network transfer, etc, but whose
> content is mostly indistinguishable from the online state)
>
> However, with the terminology around Portable Digital Document (PDD) now
> written down[2], these definitions must be re-visited. The problems I see
> are:
>
> - All defintions should be based on the PDD and there are, clearly,
> overlaps and redundancies
> - I am not sure that the terms 'offline' or 'online' are precise and
> should be used. For example, if I have a PDD on my laptop, and I serve the
> PDD through a server running on it (ie, using a URL based on
> http://localhost) then I get a proper display even if I am offline. So in
> which state would the PDD be?
>
> Here is my first attempt in reformulating the states' terms:
>
> [[[
> A Portable Digital Document can be
> • in *Unpacked State*, when all constituent Web Resources can be directly
> accessed through standard protocols like HTTP, FTP, etc.
> • in *Cached State*, when all constituents Web Resources are stored in
> the User Agent, and the final delivery of the resources in the document are
> otherwise indistinguishable from when in an Unpacked State
> • in *Packed State*, when all constituents Web Resources are combined
> into one unit for, e.g., storage in a file system, network transfer, etc.
> ]]]
>
> (I am not absolutely convinced, at this point, that the "Cached State" is
> useful, but I do not have a very strong feeling about it.)
>
> At first glance, it does not fundamentally change our requirement
> document[1] (which is good)
>
> WDYT?
>
> Ivan
>
> P.S. Note that I use "User Agent" as a more general form. This is the
> terminology we often use at W3C which, I believe, supersedes both 'Reading
> Systems' and 'Browsers'. I believe that, also in the spirit of EPUB+WEB, we
> should stick to this term…
>
>
> [1]
> https://www.w3.org/dpub/IG/wiki/Requirements_for_Web_Publication_and_Packaging
> [2] https://www.w3.org/dpub/IG/wiki/Glossary
>
>
> ----
> Ivan Herman, W3C
> Digital Publishing Lead
> Home: http://www.w3.org/People/Ivan/
> mobile: +31-641044153
> ORCID ID: http://orcid.org/0000-0003-0782-2704
>
>
>
>
>
Received on Monday, 14 September 2015 13:44:11 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:36:12 UTC