Portable Web Publications

These Slides are Available on the Web

See: http://www.w3.org/2016/Talks/EPUBSummit-IH/

(Slides are in HTML)

About W3C: “Leading the Web to its Full Potential”

• Founded in 1994, and directed by Tim Berners-Lee, the Inventor of the Web
• Member organization with cca. 420 members
• Cca. 75 staff bound to “hosts” in the USA (MIT), China (Beihang University), Japan (Keio University), and France (ERCIM)
• Focuses on Web ecosystem: users, developers, browsers, as well as specific industry requirements brought by industry segments

Digital Publishing Interest Group (DPUB IG) Origins

• W3C and IDPF organized a series of workshops in 2012 to create a missing synergy among the Web and Publishing communities
• The W3C Digital Publishing Interest Group was set up in May 2013
• DPUB IG has weekly teleconferences and bi-annual face to face meetings

DPUB IG Mission

• Experts familiar with the ins and outs of digital publishing and its associated industry groups identify issues that are not addressed by the Open Web Platform
• Goal is to raise issues to W3C working groups who can update or develop specs based on the needs of the publishing community.
• Work on a future vision of Digital Publishing called “Portable Web Publications (PWP)”

See our website for more detail.

Layout and styling

• An evolving document: “Requirements for Latin Text Layout and Pagination”
• Describes issues like hyphenation, spreads and bleeds, drop caps, pagination, etc.
• Has greatly influenced some current CSS Work, e.g. “CSS Inline Layout Module Level 3” (handling initial letters, dropcaps), or “CSS Generated Content for Paged Media Module” (handling running heads and footers)

Priorities for CSS

• Another evolving document: “Priorities for CSS from the DPUB IG”
• Provides a list of the top CSS priorities, and their current availability
• Also influences the work of the CSS Working Group

Content and markup

• Goal: identify the semantics of the HTML elements
  • “abstract”, “indexed term”, “footnote”, "chapter", …
• Express structural information (“where can that element be used”)
• Do it in a forward looking way in terms of W3C standards.
  • i.e., move away from epub:type used in EPUB 3
  • the resulting HTML should be valid
• These terms may be useful for the Web at large!

Content and markup: DPUB ARIA module

• A “Digital Publishing WAI-ARIA module” is in development
  • i.e., publishing terms become part of ARIA
• A separate document describes the mapping on the Accessibility API-s

<section role="doc-appendix">
  <h1>Appendix A. Historical Timeline</h1>
   …
</section>

Annotations

Note on DPUB Accessibility

What does this mean?

• This means:
  • publication content on the Web can be loaded into a browser or a specialized reader, whatever the user prefers
  • a publication on a local disc can be pushed onto the Web and used without any change
  • content are authored regardless of where they are used
  • these are done without any user interaction, possibly automatically

What does this mean?

For example: book in a browser

For example: book in a browser

For example: I may not be online…

For example: scholarly publishing

For example: educational publications

• What is an educational publication?
  • a book that requires offline access?
  • a packaged application with built-in interactive tests, animated examples?
  • a Web client reaching out to Web services for assessing test results, to encyclopedia, …?
  • an interactive data container storing various data for, e.g., demonstrations?
• The borderline between a “book” and a “(Web) Application” is becoming blurred…

Advantage for the publishers‘ community

Advantage for the Web community

What is a Portable Web Publication?

• A collection of Web resources considered as one unit
  • this means there is a Web address for the collection (as opposed to a single constituent)
• The user agent can render its “essential content” by relying on the Web Resources within the same Web Publication
  • this ensures that it can also be considered offline without the danger of dangling links
• The same PWP can be offline, online, archived or not archived…

What kinds of documents are we talking about?

• A journal or magazine article, including the relevant CSS files and images
• An educational article, including the JavaScript to do interactive exercises
• A novel or a poem on the Web, including the necessary fonts, CSS files, etc., to provide the required aesthetics

What kinds of documents are we not talking about?

• A Web mail application
• A social Web site like Facebook, VK, Renren, or Twitter
• A dynamic page that depends on, say, a Javascript library hosted somewhere on the cloud

But there are of course differences

• Although the we talk about the same PWP, whether offline or online, but they are obviously not 100% identical
• We refer to different states of the same PWP

Envisioned “states” of a Portable Web Publication

	Online	Offline
Packed	PWP as one archive on a server	PWP as one archive on a local disc
Unpacked	PWP spread over several files on a server	PWP spread over several files on a local disc

Envisioned architecture:
a “PWP Processor”

• A conceptual, client-side processor that “hides” the PWP state differences from the rendering engine
• The “main” rendering engine operates as if it was connected to the Web:
  • accessing resources through HTTP(S)
  • all resources are “unpacked”
• The PWP Processor should hide the state differences, possibly cache resources, etc.

Envisioned architecture:
unpacked state

Envisioned architecture:
cached state

Envisioned architecture:
packed state

Advances in modern browsers

• A browser has a hidden, truly parallel engine (a.k.a. “Service Worker”) attached to it
• That engine “catches” all calls out to the Web, and:
  • either lets it through and the original request happens;
  • or performs local processing (e.g., gets content from a cache) and returns that content instead
• The “main” rendering engine is unaware of the underlying proxy process
  • it operates as if it was connected to the Web in a traditional way

Not only a wild idea…

• Some prior art exists (e.g., experimentation by the Readium Consortium)
• An early mock-up of the current architecture has also been implemented

Is it "addressing" or is it "identification"?

• These two “roles” are different
• The usual situation:
  • some form of a URI is used to (uniquely) identify a resource
  • an HTTP(S) URL is used to address (or “locate”) a resource on the Web
• In many cases the two roles coincide, but not always
  • e.g., for a digital book:
    • URN:ISBN:1-56592-521-1 identifies the publication
    • http://www.ex.org/ex.epub addresses a particular copy

Is it "addressing" or is it "identification"?

• Identification issues are handled by a number of other organizations (DOI foundation, International ISBN Agency, etc.)
• The work on PWP has to concentrate on locators (i.e., addressing)

Three layers of addressing

1. Locator for the PWP itself:
   http://www.ex.org/MyPWP/
2. Locating a resource within a PWP:
   http://www.ex.org/MyPWP/Chapter1.html
3. Locating a target within a resource:
   http://www.ex.org/MyPWP/Chapter1.html#section1

• #3, i.e., “fragments” is defined for specific media types
• #2 should be just like any other resources on the Web, to allow for a smooth state transition

Locating the different PWP “states”

• There are, in practice, different locators
  • to the unpacked version on the Web:
    http://www.ex.org/MyPWP/dir/
  • to the package:
    http://www.ex.org/MyPWP.pwp
• Which locators should one use? How would intra-resource addressing happen?
  • i.e., how should chapter1 refer to chapter2?

Canonical locators

• A PWP must have a Canonical Locator
  • a state agnostic locator: http://www.ex.org/MyPWP
• A published PWP must provide metadata that includes all the various locators
• A PWP Processor must have access to the full metadata
• A resource within a PWP (and, in general, resources in general) should use the canonical locator only for internal cross-references (or use relative URL-s)

The PWP Processor can take care of the rest…

• The processor has an access to all states and their locators
• It can, if needed, convert among URI requests coming from the renderer
• Remember:

• A conceptual, client-side processor that “hides” the PWP state differences from the rendering engine
• The “main” rendering engine operates as if it was connected to the Web:
  • accessing resources through HTTP(S)
  • all resources are “unpacked”
• The PWP Processor should hide the state differences, possibly cache resources, etc.

Manifests

• Note the crucial importance of the metadata
• Some sort of a “manifest” format should be defined to hold (among others) this metadata
• The manifest will be used for other, more traditional reasons, too:
  • “traditional” metadata like author(s), right expressions, publication dates,…
  • identifiers
  • correct reading order for the publication content
  • etc.

• What is the level of user control of the presentation?
• The Web and eBook traditions are vastly different:
  • in a browser, the Web designer is in full control
    • CSS alternate style sheets or user style sheets are hardly in use
    • some user interface aspects can be controlled but only for the browser as a whole
  • in an eBook reader, there is more user control
    • foreground/background color
    • choice of fonts
• There is a need to reconcile these traditions

IDPF, W3C, and others

• On long term, some PWP related standard-track specification work may have to be done
  • this requires a consensus and agreement of different communities
• IDPF and W3C (and maybe others?) may create the necessary groups, eventually

DPUB IG and Portable Web Publications

• “Portable Web Publications” was, originally, a separate “vision” document
• Was adopted, formally, as part of the group’s work in September 2015, and is now published as an IG document
• The group will contribute to the formulation of the PWP technical challenges, to a better understanding of the requirements
• PWP is the guiding principle for the group’s further work

PWP vs. EPUB3.1

• PWP does not replace EPUB 3.1
• Many of the new features discussed as part of EPUB 3.1 (e.g., structural semantics, manifests) already go in direction of something like PWP
• Others (like the locator structure) from the work on PWP may influence the evolution of EPUB 3.1, mainly in the area of BFF

Many (most?) things are the same!

• The content of a PWP and EPUB 3.1 are identical
  • usage of HTML, CSS, SVG, SMIL, etc.
• What would change is the “administrative” aspect of the publication (locators, manifest, etc)

PWP and future EPUB-s

• The structure of PWP is very general
• Specific publication areas may need more restrictions and specifications
  • metadata vocabularies, specific format for glossaries or indeces,…
  • many of these features are already defined in EPUB 3
• A future EPUB may be defined as a profile of PWP
  • taking over or adapting a number of existing parts of EPUB 3.1
  • a bit like EDUPUB is a profile of EPUB 3
• There may be other profiles for, e.g., online magazines

Some references

DPUB IG Wiki

https://www.w3.org/dpub/IG/wiki/Main_Page

Latest PWP Official Draft:

http://www.w3.org/TR/pwp/

PWP Editors’ draft:

https://w3c.github.io/dpub-pwp/

PWP Issue list:

https://github.com/w3c/dpub-pwp/issues

Thank you for your attention!

This presentation:

http://www.w3.org/2016/Talks/EPUBSummit-IH/

A companion, a bit more technical, presentation

http://www.w3.org/2016/Talks/W3CTrack-IH/

My contact:

ivan@w3.org