Digital Publishing Interest Group Teleconference

21 Nov 2016


See also: IRC log


Dave Cramer (dauwhe), Tzviya Siegman, Luc Audrain (laudrain), Chris Maden (cmaden2), Alan Stearns (stearns), Ivan Herman, Avneesh Sing, Deborah Kaplan, Charles LaPierre, Bert Bos, Garth Conboy, Bill Kasdorf, Vladimir Levantovksy, Romain Deltour, George Kerschner
Leonard Rosenthol, Karen Myers, Ben De Meester, Laurent Le Meur


  1. Updated DPUB-PWP
    1. Epub4 vs. Profiles
    2. Title of the document
    3. API sections
    4. locators
  2. CSS TPAC Actions
    1. Media Queries in HTML
    2. Character based alignments
    3. Hanging punctuation
    4. Usage of WICG Discourse

<tzviya> https://www.w3.org/2016/11/14-dpub-minutes.html

<scribe> scribenick: cmaden2

tzviya: minutes approved

<tzviya> https://w3c.github.io/dpub-pwp/

Updated DPUB-PWP

tzviya: ivan proposed changed to dpub-pwp over last two years… asked for proposals last week. there are a few things in GitHub, picking it up again this week.

ivan: to clarify what i did: toc is main thing to look at. Lots of discussion around use cases, which have restructured our thinking. dpub-pwp is now reorganized around that approach.
... reshuffled, very little editorial change. Old technical section (§4); some sections mostly empty.
... Empty sections on api, pub object model, maybe we don’t even want that.
... §5 also needs more thorough review

Epub4 vs. Profiles

ivan: section on epub4 also needs complete rewrite

bill: my opinion is epub should be a profile of pwp; could be discussed in §5, instead of having its own section

ivan: there was a whole section on epub3 vs. pwp because everybody asked. being able to describe epub in terms of pwp would also be a good response… ivan needs input

tzviya: reminder that ivan is not going to be the sole author of this document. we all need to provide input.

bill: i can take that on, will try to use epub and a few other examples to consider as pwp profiles

Title of the document

ivan: what should the title of the document be?
... packaging is a separate notion from web publication… open web pub (owp)?

tzviya: matt garrish is editor of epub specs, would be useful reviewer. tzviya and he are OK with web pub being title, packaging being an additional thing, though some people think packaging is superimportant.

dave: i support calling it web publication. packaging in title does more harm than good.

ivan: i use “pwp” or “wp” as abbrs, but sometimes “(p)wp.”
... but how to refer to publication, whether packaged or not?

dave: web pub in title, but packaged (lc) web publication is just a kind of web pub…

bill: pwp could even be a profile of a wp.

garth: we need to be careful to keep packaging prominent and important

bill: profile was sort of a joke, since the pub needs to be packageable

george: as an author, i see creating a publication locally, then packaging it for distribution, unpacked for web publication. that’s how i see one way of using it.
... how i see lots of them being created.

luc: second george, information must be gathered for publication, is a kind of packaging, so pwp is ok

API sections

tzviya: additional apis section. does that belong in *this* document, or something auxiliary? a technical or api doc?

ivan: i see specification as layered. document collection api. In html land, api is one single dom; going over multiple doms needed to do things like pagination. Similar to idea that web pub is just a collection of resources… so the idea of the api does fit into this document. Next layer is more complicated; anyone who has programmatically interacted with epub knows it’s complicated.
... that layer is more practical, a way to standardize the way to hide the complexity of the web pub.
... it’s one person’s mostly-unchecked proposal, and the community is quiet, so maybe it doesn’t belong here.

tzviya: it’s important, and we aren’t the only ones with the ideas (as this week’s activity shows), but maybe this is the wrong place to discuss this.

dave: idea of an api to deal with pubs is important; we may not know what shape it will take, but we need something in the doc that says this will be a key piece.

ivan: This doc is not a technical spec, so it’s fine to say, “these items are important and have to be solved.” even if we or a wg don’t solve it, it’s still good to note that this an important part of the eventual technical spec.

garth: was going to go the other way, but dave and ivan changed my mind. we need to be careful not to predispose the chartering effort, but ivan makes good points. potentially a “boil the ocean” area… was going to say remove these, but ivan’s position that it’s potential input is good… equivocation.

tzviya: consensus seems to be that we need to keep these mentions in the document.

george: is this a long doc?

tzviya: no, though that depends on perspective…

<tzviya> https://github.com/w3c/dpub-pwp/issues/29


tzviya: packaged, unpackaged, and canonical locators. do we need locators for resources inside a packaged publication?
... ! locators; and do we need separate canonical locators? use of “canonical” may be confusing or misleading.
... hadrien suggested hrefsrc attribute.

ivan: original use case… what may have changed is that we made a big deal about difference between online and offline versions. after discussions, that divide may not be that important any more. packaged vs. unpackaged is a bigger deal.
... look at original use cases (in ucr) and start discussion over again.

tzviya: there was context missing from original discussions, concept of state. do we really need to create what is really a fragment identifier. dave suggests we can use what’s already out there, and hadrien’s suggestion was similar.

bill: we came up with “canonical” because we couldn’t come up with a publication identifier. also, completely agree with reusing already-extant things, esp. use annotation wg for identifiers.

tzviya: annotations doesn’t have one fragment id, uses whatever.

bill: yes, align with them. fragment in video is different from text, and that’s ok and appropriate.

<ivan> http://w3c.github.io/web-annotation/selector-note/index-respec.html

<ivan> http://w3c.github.io/web-annotation/selector-note/index-respec.html#frags

ivan: yes and no… annotation rec does not define fragment. selector note (not a standard) does have a way to translate selectors into fragment ids and back. ugly, but it works.

bill: aligning with annotations is good, but maybe not sufficient. still need to identify the publication itself.

ivan: these are different questions; we should not get into how to identify a publication.

bill: that’s what canonical locators were for.

ivan: we can extend and standardize annotation fragment identifiers, if that’s something we want to do. not sure if we do, but it’s possible.

dave: motivation for filing this issue was, what is the function of the packaged or portable pub? seems to treat packaged as a peer of unpackaged, fully equivalent. my thinking is that the package is for transmissal, unpacked by recipient, and then the same as unpackaged, effectively. i’m susceptible to epub bias; we should try to avoid that.

garth: i think there will still be reading systems that think of rendering a packaged item. that’s an important constituency.

tzviya: though it seems that the exploded epub is the mo for reading systems.

garth: clearly you take it apart to render it.

<astearns> unpacking/exploding is perhaps just done in order to load a browser's cache?

bill: unpackaging doesn’t mean exploding with parts everywhere, more unwrapping, still together, still in relationships, but not in the package any more.

hadrien: as long as a resource in a package can be traced to a uri on the web, we don’t need to worry about packaged/unpacked. what’s the uri for the publication, and what’s the uri for a particular resource, is sufficient to handle any case, packaged/unpackaged, online/offline.

ivan: that’s very close to what we said. the manifest is a way to have the unique identifier of this thing and its location on the web. any processor can switch between the two as needed.

CSS TPAC Actions

<tzviya> https://lists.w3.org/Archives/Public/public-digipub-ig/2016Nov/0035.html

tzviya: we have action items from tpac we committed to.
... feedback on media queries level 4. if you committed to something, please work on it.

<astearns> liam has been working on his task

Media Queries in HTML

tzviya: media queries in mathml; there’s been some work.

george: collected examples people sent, but haven’t identified time to go through it with the group.

tzviya: pkra had concerns, too; touch base with him.

charles: we stopped work on it because we don’t think media queries will do what we want to do. george and i are now thinking about image and fallback, offscreen mathml… possibly no longer to do with css.

avneesh: mathml short-term solution, providing techniques. long-term, we may collaborate with css. not leaving it, but it’s a long-term thing.

Character based alignments

tzviya: character-based alignment. dave had committed to getting examples. dino said he’d get it on apple’s radar. i committed to sending some examples. anyone else?

luc: got samples of ways *not* to do it. looking for good samples.

tzviya: will send crazy table examples more broadly.
... css vs. xsl-fo. liam has been working on this.
... page-floats. johannes has done some work, needs better error handling. is anything needed from us? dave will let us know.
... hanging punctuation. (type nerds!!!)

Hanging punctuation

dave: originally designed for cjk, could property values be adapted to western languages? what should happen, how much control do authors need?
... accessibility questions are particularly interesting… will ask for anything he needs

Usage of WICG Discourse

<tzviya> https://discourse.wicg.io/t/proposal-list-head-caption-title/1832

tzviya: things we want from the broader w3c community. talked with robin berjon, proposal for list title in web community incubator. well-received, draft spec.
... if there are other things we want, this is how we ask for it. dave has suggested a dpub label. comment on the item in wicg, don’t just e-mail me.

ivan: i think i can set up that label.

tzviya & ivan: go ahead and make proposals there, too. worst that can happen is no1curr

ivan: do i have action items on the doc?

tzviya: can wait till next week.

Summary of Action Items

Summary of Resolutions

[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.148 (CVS log)
$Date: 2016/11/22 10:06:27 $