See also: IRC log
<tzviya> https://www.w3.org/2016/11/14-dpub-minutes.html
<scribe> scribenick: cmaden2
tzviya: minutes approved
<tzviya> https://w3c.github.io/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
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
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
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.
<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
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.
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!!!)
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
<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.