The Convergence of Digital Publishing and the Web

These Slides are Available on the Web

See:
http://w3c.github.io/dpub/markup-forum-2015-11/index.html/

(Slides are in HTML)

DPUB IG Origins

• The publishing industry is, probably, the most important user of W3C’s Web technologies after (traditional) browsers:
  • almost all journals, magazines, etc., have an online version these days
  • scholarly publishing cannot exist without the Web any more
  • EPUB is, essentially, a frozen and packaged Web site
• The quality requirements of this industry are very high:
  • high quality typesetting, graphics, etc.
  • new forms of publishing will be based on high level of interactions, rich media, …
  • common document and data publishing comes to the fore

DPUB IG Origins (cont.)

• But… the publishing industry had been in an entirely “passive” mode v.a.v. Web technologies
  • no participation in the development of fundamental Web technologies
  • W3C (and many other standard bodies) hardly know about the requirements that this industry may have
  • the potential synergy between Web developers and publishers is missed out
• Consequence: Working Groups at W3C set their priorities without knowing about, and considering, the publishing industry

DPUB IG Origins (cont.)

• W3C and IDPF organized a series of exploratory workshops in 2012 to create a missing synergy among communities
• The W3C Digital Publishing Interest Group was formally created 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.

IDPF and W3C

The key is strong collaboration.

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: Approach Chosen

• Use “Accessible Rich Internet Applications (WAI-ARIA)” as a basic mechanism:
  • use specific attributes in HTML
  • attribute values convey a specific semantics

These semantics are designed to allow an author to properly convey user interface behaviors and structural information to assistive technologies in document-level markup

Content and Markup: DPUB ARIA module

• A Digital Publishing ARIA module is in development
• Publishing terms become part of ARIA
• Extra bonus: these terms directly mapped on Assistive Technologies interfaces!

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

Annotations

• Published an Annotation Use Cases
• Activity and work has shifted to the Web Annotations Working Group
  • the work aims at annotation for all forms of Web Documents, whether in a browser or an eBook

What does this mean?

• Separation between publishing “online”, as Web sites, and offline and/or packaged is diminished to zero
• 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 (or only very minimal one)

For Example: Book in a Browser

• On a desktop I may want to read a book just like a Web page:
  • easily follow a link “out” of the book
  • create bookmarks “into” a page in a book
  • use useful plugins and tools that my browser may have
  • create annotations

For Example: Book in a Browser (cont.)

• But:
• sometimes I may also want to use a small, dedicated reader device to read the book on the beach…
• All these on the same book (not conversions from one format to the other)!

For Example: I May Not Be Online…

• I may find an article on the Web that I want to review, annotate, etc., while commuting home on a train
• I want the results of the annotations to be back online, when I am back on the Internet
• Note: some browsers have an “archiving” possibility, but they are not interoperable
  • the content can definitely not be read on a dedicated reader

For Example: Scholarly Publishing

• My paper is published, primarily, on-line, but people may want to download it for offline use
• The format of the paper should be adaptable to my reading environment
  • do not want a two column, fixed layout file that I cannot handle on my iPad…
• My “paper” may also contain video, audio, data, programs…
  • scholarly publishing is not text only any more!

For Example: Educational Materials

• 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” are becoming blurred!

Advantage for Publishers‘ Community

• Publishers want to concentrate on what they know better: how to produce, edit, curate, etc, great content
• Publishers are not technology companies, nor do they intend to be; they want instead to rely on the vibrant Web community!

Advantage for Publishers‘ Community (cont.)

• OWP is more than “just” HTML, CSS, MathML, etc.
• It also defines a large number of facilities that provide access to, e.g., system resources or utilities
  • index database, Web storage, battery status API, real-time communication, geolocation,…
• Aligning more on OWP means that publishing oriented devices, software, services, etc, can rely on those
  • instead of possibly re-inventing the wheel…

Advantage for the Web Community

• Publishers have a long experience in ergonomics, typography, paging, …
• Publishing long texts, with the right aesthetics, readability, structure, etc., is an expertise the Web community can profit from
• Experience of publishers in the complete workflow for producing content may become important for Web design

Several reasons…

• The future may be that everyone is always connected… but the reality is different
  • slow connections, e.g., or on a plane or bus or even in some areas
  • huge roaming prices among countries
• Current publishing business models rely on distributable entities
• Privacy or security issues may require off-line access
  • e.g., in a plane cockpit
• Archiving considerations

• A strong cooperation between the different communities should be ensured
• Technical challenges must be identified
  • note that some of the challenges are not PWP specific, but Digital Publishing in general (e.g., pagination control)
• Some examples follow…

Web Publications

• On the current Web one has the notion of a “page”:
  • conceptually, a single entity that displays some content
  • has its own URL
• But publishers need the concept of a (Web) Publication:
  • a collection of pages, CSS files, images, video, etc.
  • it is the collection that has a distinct identity, not its constituents

Formally

• A Web Publication is an aggregated set of interrelated Web Resources, and which is intended to be considered as a single, and which can be addressed on the Web as a unit (is itself a Web Resource)

Portable Web Publications

• A Web Publication may consist of resources spread all over the place (HTML on one site, CSS somewhere else)
  • the owner of the Web Publication is only a “user” and not necessarily the owner of all resources!
• But a publishers may want to, create, curate, move the whole publication, as a single unit
• The Web Publication should be, in some sense, “self consistent”, not relying on external entities.
• A “self-consistent” Web Publication is Portable

More Formally

• A Portable Web Publication is such that a user agent can render its essential content by relying on the Web Resources within the same Web Publication

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, Renren, or Twitter
• A dynamic page that depends on, say, a Javascript library hosted somewhere on the cloud

Envisioned “states” of a Portable Web Publication

Advances in modern browsers: Web and Service Workers

• Web Worker: a truly parallel thread within the browser
• A Service Worker is a special type of Web Worker, with additional features:
  • it is a programmable network proxy: the main thread’s network calls are caught and the request/answer can be modified on-the-fly behind the scenes
  • it has an interface to handle a local cache for networked data
  • it will stay alive even if the user moves away from the main page, and can be accessed later if he/she returns to it

Advances in modern browsers: Web and Service Workers

• Web Worker: a truly parallel thread within the browser
• A Service Worker is a special type of Web Worker, with additional features:
  • it is a programmable network proxy: the renderer’s network calls are caught and the request/answer can be modified on-the-fly behind the scenes
  • it has an interface to handle a local cache for networked data
  • it will stay alive even if the user moves away from the main page, and can be accessed later if he/she returns to it

Work in progress

Envisioned Architecture:
unpacked state

Envisioned Architecture:
cached state

Envisioned Architecture:
packed state

Envisioned Architecture:
packed state

Draft…

Draft indeed, but…

• Some prior art exists (e.g., experimentation by the Readium Consortium with Service Workers)
• An early mock-up of the current architecture has also be done
  • caveat for now: current Service Worker specification does not allow for direct, local file access
  • some extra tricks have to be found

Rough structure of an EPUB3 file

Archival Format

• There is an interest among some W3C members for a Web friendly packaging format:
  • should be streamable
  • should rely, as much as possible, on existing Web technologies (e.g., HTTP)
• Use cases include:
  • retrieve an HTML file with related CSS files, images
  • access Web Applications (“Widgets”) with all libraries involved
  • Portable Web Publications are a clear use case
• But: current Web Packaging proposal is not OPF based
  • this may lead to a different packaging in future for Digital Publishing

PWP packaging structure

However…

• There isn‘t yet a full agreement to develop such Web Packaging format
  • for some a caching architecture based on Service Workers is enough for the use cases
• If that happens, the Publishing Community may not move away from OPF
  • technical advantages of a new format must be weighted against existing deployment

Is it "Addressing" or is it "Identification"?

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

What does an HTTP GET return?

• Possibilities may be
  • some sort of a manifest describing the PWP as a whole (e.g., metadata, content, etc.); or
  • some content with a link to a manifest through a LINK: HTTP response header entry; or
  • some HTML content with a link to a manifest through a <link> element
• Details of what a manifest contains should be worked out
  • that may become a crucial constituent of a PWP

What is the URL of a resource within a PWP?

• Several possibilities should be considered:
  • based on some sort of a fragment identifier: http://www.ex.org/doc.pwp#pwp(…)
  • explicit separator between the URL for the publication and the rest: http://www.ex.org/doc.pwp!chapter1.html
  • simulate “tree” view of the publication’s content: http://www.ex.org/doc.pwp/chapter1.html
• The third case is the most “webby”
  • it may need some extra information (“virtual redirection”) in, e.g., a manifest if the resources are spread all over the place
• Decomposing such URLs would happen in the dedicated Service Worker

What about addressing within a resource?

• This is exactly what fragment identifiers do on the Web
• PWP-s should not define a different mechanism, but should rely on what is widely deployed
  • note that this pretty much excludes http://www.ex.org/doc.pwp#pwp(…) as an answer to the previous question
• Although… new types of fragment identifers may be proposed by the publishing community to the Web community at large

• 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 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

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

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

However…

• PWP does not replace EPUB 3 (and upcoming EPUB 3.1) at this moment
• Many of the new features may also be part of EPUB 3.1 (e.g., structural semantics)
• The vision is a convergence of the EPUB 3.* specifications and PWP, eventually

Conclusion

• There is a great potential in a convergence between the Open Web Platform and Portable Web Publications
• It will require a common effort and cooperation of both communities
• But it is an exciting prospect!

Some references

DPUB IG Wiki

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

Latest PWP Draft:

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

PWP Issue list:

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

This presentation:

http://w3c.github.io/dpub/markup-forum-2015-11/index.html (PDF is also available for download)

Contact me:

ivan@w3.org