Portable Web Pub­li­ca­tions: Tech­nol­ogy Chal­lenges

These Slides are Avail­able on the Web

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

(Slides are in HTML)

What does this mean?

• This means:
  • pub­li­ca­tion con­tent on the Web can be loaded into a browser or a spe­cial­ized reader, what­ever the user prefers
  • a pub­li­ca­tion on a local disc can be pushed onto the Web and used with­out any change
  • con­tent are au­thored re­gard­less of where they are used
  • these are done with­out any user in­ter­ac­tion, pos­si­bly au­to­mat­i­cally

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: educational publications

• What is an ed­u­ca­tional pub­li­ca­tion?
  • a book that re­quires of­fline ac­cess?
  • a pack­aged ap­pli­ca­tion with built-in in­ter­ac­tive tests, an­i­mated ex­am­ples?
  • a Web client reach­ing out to Web ser­vices for as­sess­ing test re­sults, to en­cy­clo­pe­dia, …?
  • an in­ter­ac­tive data con­tainer stor­ing var­i­ous data for, e.g., demon­stra­tions?
• The bor­der­line be­tween a “book” and a “(Web) Ap­pli­ca­tion” is be­com­ing blurred…

Advantage for the publishers‘ community

Advantage for the Web community

Several reasons…

• The fu­ture may be that every­one is al­ways con­nected… but the re­al­ity is dif­fer­ent for many years to come
  • slow con­nec­tions, e.g., or on a plane or bus or even in some areas
  • huge roam­ing prices among coun­tries
• Cur­rent pub­lish­ing busi­ness mod­els rely on dis­trib­utable en­ti­ties
• Pri­vacy or se­cu­rity is­sues may re­quire off-line ac­cess
  • e.g., in a plane cock­pit
• Archiv­ing con­sid­er­a­tions

Web Publications

Web Publications

Formally

Portable Web Publications

• A Web Pub­li­ca­tion may con­sist of re­sources spread all over the place (HTML on one site, CSS some­where else)
  • the owner of the Web Pub­li­ca­tion is only a “user” and not nec­es­sar­ily the owner of some of those re­sources!
• But a pub­lish­ers may want to, cre­ate, cu­rate, move the whole pub­li­ca­tion, as a sin­gle unit
• The Web Pub­li­ca­tion should be, in some sense, “self con­sis­tent”, not re­ly­ing on ex­ter­nal en­ti­ties.
• A “self-con­sis­tent” Web Pub­li­ca­tion is there­fore Portable

More Formally

• A Portable Web Pub­li­ca­tion is such that a user agent can ren­der its es­sen­tial con­tent by re­ly­ing on the Web Re­sources within the same Web Pub­li­ca­tion

What kinds of documents are we talking about?

• A jour­nal or mag­a­zine ar­ti­cle, in­clud­ing the rel­e­vant CSS files and im­ages
• An ed­u­ca­tional ar­ti­cle, in­clud­ing the JavaScript to do in­ter­ac­tive ex­er­cises
• A novel or a poem on the Web, in­clud­ing the nec­es­sary fonts, CSS files, etc., to pro­vide the re­quired aes­thet­ics

What kinds of documents are we not talking about?

• A Web mail ap­pli­ca­tion
• A so­cial Web site like Face­book, VK, Ren­ren, or Twit­ter
• A dy­namic page that de­pends on, say, a Javascript li­brary hosted some­where on the cloud

But there are of course differences

• Al­though the same con­tent of a PWP whether of­fline or on­line, but they are ob­vi­ously not ab­solutely the same
• We refer to dif­fer­ent states of the same PWP

Envisioned “states” of a Portable Web Publication

	Pro­to­col Ac­cess	File Ac­cess
Packed	PWP as one archive on a server	PWP as one archive on a local disc
Unpacked	PWP spread over sev­eral files on a server	PWP spread over sev­eral files on a local disc

Envisioned architecture:
a “PWP Processor”

• A con­cep­tual, client-side proces­sor that “hides” the PWP state dif­fer­ences from the ren­der­ing en­gine
• The “main” ren­der­ing en­gine op­er­ates as if it was con­nected to the Web:
  • ac­cess­ing re­sources through HTTP(S)
  • all re­sources are “un­packed”
• The PWP Proces­sor should hide the state dif­fer­ences, pos­si­bly cache re­sources, etc.

Envisioned architecture:
unpacked state

Envisioned architecture:
cached state

Envisioned architecture:
packed state

Advances in modern browsers: Web and Service Workers

• Web Worker: a truly par­al­lel thread within the browser
• A Ser­vice Worker is a spe­cial type of Web Worker, with ad­di­tional fea­tures:
  • it is a pro­gram­ma­ble net­work proxy: the ren­derer’s net­work calls are caught and the re­quest/an­swer can be mod­i­fied on-the-fly be­hind the scenes
  • it has an in­ter­face to han­dle a local cache for net­worked data
  • it will stay alive even if the user moves away from the main page, and can be ac­cessed later if he/she re­turns to it

Not only a wild idea…

• Some prior art ex­ists (e.g., ex­per­i­men­ta­tion by the Rea­d­ium Con­sor­tium with Ser­vice Work­ers)
• An early mock-up of the cur­rent ar­chi­tec­ture has also been done
  • caveat for now: cur­rent Ser­vice Worker spec­i­fi­ca­tion does not allow for di­rect, local file ac­cess
  • some extra tricks have to be found

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

• These two “roles” are dif­fer­ent
• The usual sit­u­a­tion:
  • some form of a URI is used to (uniquely) iden­tify a re­source
  • an HTTP(S) URL is used to ad­dress (or “lo­cate”) a re­source on the Web
• In many cases the two roles co­in­cide, but not al­ways
  • e.g., for a dig­i­tal Book :
    • URN:ISBN:1-56592-521-1 iden­ti­fies the pub­li­ca­tion
    • http://www.ex.org/ex.epub ad­dresses a par­tic­u­lar copy

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

• Iden­ti­fi­ca­tion is­sues are han­dled by a num­ber of other or­ga­ni­za­tions (DOI foun­da­tion, In­ter­na­tional ISBN Agency, etc.)
• The work on PWP has to con­cen­trate on lo­ca­tors (i.e., ad­dress­ing)

Three layers of addressing

1. Lo­ca­tor for the PWP it­self:
   http://www.ex.org/MyPWP/
2. Lo­cat­ing a re­source within a PWP:
   http://www.ex.org/MyPWP/Chapter1.html
3. Lo­cat­ing a tar­get within a re­source:
   http://www.ex.org/MyPWP/Chapter1.html#section1

• #3, i.e., “frag­ments” is de­fined for spe­cific media types
• #2 should be just like any other re­sources on the Web, to allow for a smooth state tran­si­tion

Locating the different PWP “states”

• There are, in prac­tice, two dif­fer­ent lo­ca­tors
  • to the un­packed ver­sion on the Web (L_u):
    http://www.ex.org/MyPWP/dir/
  • to the pack­age (L_p):
    http://www.ex.org/MyPWP.pwp
• Which lo­ca­tors should one use? How would in­tra-re­source ad­dress­ing hap­pen?
  • i.e., how should chapter1 refer to chapter2?

Canonical locators

• A PWP must have a Canon­i­cal Lo­ca­tor (L)
  • a state ag­nos­tic lo­ca­tor: http://www.ex.org/MyPWP
• A pub­lished PWP must pro­vide meta­data that in­cludes L, L_p, and L_u
• A PWP Proces­sor must have ac­cess to the full meta­data
• A re­source within a PWP (and, in gen­eral, re­sources in gen­eral) should use L only for in­ter­nal cross-ref­er­ences (or use rel­a­tive URL-s)

The PWP Processor can take care of the rest…

• The proces­sor has an ac­cess to L, L_p, and L_u
• It can, if needed, con­vert among URI re­quests com­ing from the ren­derer
• Re­mem­ber:

• A con­cep­tual, client-side proces­sor that “hides” the PWP state dif­fer­ences from the ren­der­ing en­gine
• The “main” ren­der­ing en­gine op­er­ates as if it was con­nected to the Web:
  • ac­cess­ing re­sources through HTTP(S)
  • all re­sources are “un­packed”
• The PWP Proces­sor should hide the state dif­fer­ences, pos­si­bly cache re­sources, etc.

What does an HTTP GET return for L?

• Pos­si­bil­i­ties are:
  • the full man­i­fest
  • the pack­age that in­cludes the man­i­fest at some pre­de­fined place
  • an HTML file with a link to a man­i­fest (through a <link> el­e­ment)
  • an HTML file with an em­bed­ded man­i­fest (through a <script> el­e­ment)
  • some Web Re­source, with a link to a man­i­fest in the Link header of the HTTP re­sponse
• A PWP Proces­sor should con­sider all these pos­si­bil­i­ties and com­bine the var­i­ous sources
• Dif­fer­ent server se­tups are pos­si­ble; a PWP spec­i­fi­ca­tion should leave that open

Getting hold of all locators

Manifests

• Note the cru­cial im­por­tance of the meta­data
• Some sort of a “man­i­fest” for­mat should be de­fined to hold (among oth­ers) this meta­data
• The man­i­fest will be used for other, more tra­di­tional rea­sons, too:
  • “tra­di­tional” meta­data like au­thor(s), right ex­pres­sions, pub­li­ca­tion dates,…
  • iden­ti­fiers
  • cor­rect read­ing order for the pub­li­ca­tion con­tent
  • etc.

• What is the level of user con­trol of the pre­sen­ta­tion?
• The Web and eBook tra­di­tions are vastly dif­fer­ent:
  • in a browser, the Web de­signer is in full con­trol
    • CSS al­ter­nate style sheets or user style sheets are hardly in use
    • some user in­ter­face as­pects can be con­trolled but only for the browser as a whole
  • in an eBook reader, there is more user con­trol
    • fore­ground/back­ground color
    • choice of fonts
• There is a need to rec­on­cile these tra­di­tions

DPUB IG and Portable Web Publications

• “Portable Web Pub­li­ca­tions” was, orig­i­nally, a sep­a­rate “vi­sion” doc­u­ment
• Was adopted, for­mally, as part of the group’s work in Sep­tem­ber 2015, and is now pub­lished as an IG doc­u­ment
• The group will con­tribute to the for­mu­la­tion of the PWP tech­ni­cal chal­lenges, to a bet­ter un­der­stand­ing of the re­quire­ments
• PWP is the guid­ing prin­ci­ple for the group’s fur­ther work

IDPF, W3C, and others

• On long term, some PWP re­lated stan­dard-track spec­i­fi­ca­tion work may have to be done
  • this re­quires a con­sen­sus and agree­ment of dif­fer­ent com­mu­ni­ties
• IDPF and W3C (and maybe oth­ers?) may cre­ate the nec­es­sary groups, even­tu­ally

Some references

DPUB IG Wiki

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

Lat­est PWP Of­fi­cial Draft:

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

PWP Ed­i­tors’ draft:

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

PWP Issue list:

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

Thank you for your at­ten­tion!

This pre­sen­ta­tion:

http://www.w3.org/2016/Talks/W3CTrack-IH/
(PDF is also avail­able for down­load)

My con­tact:

ivan@​w3.​org