Digital Publishing IG Telco

<ivan> Date: 2015-05-01

Really interesting discussion of packaging in the public-web-perf ML. One highlight: https://lists.w3.org/Archives/Public/public-web-perf/2015Jan/0041.html

<tmichel> The audio is really bad. can't understand anything ...

<tzviya> for call in information, see http://www.w3.org/dpub/IG/wiki/WebEx

all: gnashing of teeth around audio issues

tzviya: first we will approve minutes

<tzviya> http://www.w3.org/2015/05/17-dpub-minutes.html

tzviya: minutes from last phone call
... any comments?

[crickets]

Tzviya: minutes are approved
... thanks to Ivan for summarizing F2F and doing tons of other work

<tzviya> http://www.w3.org/2015/05/26-dpub-minutes.html

Tzviya: any comments on F2F minutes?

[crickets]

<HeatherF> Yay for scribes!

scribe: we will stipulate that all have read the minutes.
... minutes are approved.
... next item is recap of F2F, so let's take a look at Ivan's summary

F2F Recap

<HeatherF> https://gist.github.com/anonymous/6d1eb70a7eb2ba2a067e

<ivan> sumary fo f2f: http://www.w3.org/blog/dpub/2015/05/30/dpub-ig-face-to-face-2015-05-26/?pk_campaign=feed&pk_kwd=dpub-ig-face-to-face-2015-05-26

Tzviya: we had an excellent F2F
... we have lots of work ahead
... [1] Packaging
... we need to define core requirements, and decide if we need packaging
... [2] identifiers, and laying out requirements
... [3] pagination, and relationship to CSSWG and Houdini. Dave will be talking to CSSWG
... [4] a11y. Defining goals of task force, working on docs
... serving as liason with other publishing groups like BISG
... [5] Education outreach
... people don't know what we do now
... we have blog, slides, etc
... [6] rechartering
... and the future of this group over next two years
... any comments?

[crickets]

Karen_: thanks to IDPF board members for attending, and Diane Kennedy from IDEAliance

tzviya: it was good to have a diverse group

laudrain: reading the summary, i was wondering about education
... did you speak about edupub?

tzviya: we talked about educating the publishing community, not about edupub as a topic
... Ivan, Markus, and Ralph discussed rechartering on Friday

Charter recap

<ivan> https://github.com/w3c/dpub-charter/issues

ivan: I collected the various items on what we decided
... and put up as series of issues on github

<tzviya> https://github.com/w3c/dpub-charter/labels/DPUB%20IG%20comments

ivan: 1 issue is to make it clear that the new group is not completely new
... we must follow up on work already started
... the other thing is possible misunderstanding on epubweb story
... and there were conflicting misunderstandings
... some voices seemed to understand this is a profile of epub like edupub is a profile of epub; this is not true
... others were afraid that it's throwing epub 3.01 out of the window; this is not true
... this is also not restricted to books, also includes journals and magazines; this is true :)
... what is a possible alternative name for epubweb?
... we did not find a consensus, as all possible names have downsides
... and we could easily descend into css-style bikeshedding
... we could call the whole thing EPUB+WEB
... (emphasis on "+")
... may be temporary, but I don't have anything better
... there are stylistic issues
... Heather pointed us to an IETF draft on packaging
... it's not an alternative to w3c spec, but rather having a top-level name for package, then package/epub etc

<HeatherF> http://datatracker.ietf.org/wg/arcmedia/charter/

ivan: this shows that whole issue of packaging is interesting, and lots of people are thinking of it
... that's what happened on the charter
... I'm busy changing the charter, you can see it on new branch on github
... the biggest problem is the deliverables and milestones
... i hope a new draft will be available on Tuesday or Wednesday
... and I really really really really really really want comments
... tzviya, did I forget anything?

tzviya: I'd cut down on number of issues, and focus on big ones, like packaging, identifiers, pagination
... not everything we work on will be in charter, as they fall under bigger issues
... we'll have milestones and even deadlines

<ivan> https://rawgit.com/w3c/dpub-charter/post-f2f/index.html current draft

ivan: this is the current draft
... Does HeatherF have any comment on IETF work?

<pkra> take the red pill.

HeatherF: the arcmedia group is still mostly getting started, a good time to get engaged
... the next ietf meeting is July in Prague; most work is done on mailing lists

ivan: will you be there?

HeatherF: Yes

ivan: that will be interesting!

tzviya: I wanted to stress is that this the point where we decide what we're doing for the next two years
... this is the soul-searching moment
... speak now!
... or else.

[mysterious beep]

<HeatherF> I haven't had a chance to review the latest text, but I have it on my list for this week.

Packaging Requirements

<tzviya> https://www.w3.org/dpub/IG/wiki/Functional_Requirements#Functional_Requirements_for_Packaging_Spec

tzviya: We need to start to put together functional requirements for various things
... I wrote up some functional requirements for packaging, dauwhe added a few comments
... [reading from requirements]

ivan: I don't understand "multiple methods of navigation"

tzviya: in addition to trad toc, we need a list of tables, etc
... might not be part of packaging, or something you build out of ARIA

HeatherF: with regards to no file size limitations, I thought we decided the operating systems may be the problem
... so I'm not sure if we can do anything

brady_duga: at the end of the day it's nice to say there's no file size limits
... i've seen 600k CSS files, but we handle it slowly
... we can't handle arbitrarily large content, in practice there will be limits
... in terms of zip, reading systems must support zip 64
... if you give me a book larger than zip64 limit, I refuse to process
... so I don't thing there's a serious limit in epub today

tzviya: how would you modify the file size comment

brady_duga: saying there's no limit is impossible because physics
... a really huge limit is fine
... any limit we set today will be meaningless in five years

tzviya: does that work for you

HeatherF: I'm sad we can't just say, "Don't be stupid!"

<HeatherF> :-)

tzviya: anything else, brady?

ivan: there's a minor thing
... maybe we want to add possibility of heirarchy
... you already do this in edupub

tzviya: I'll add this

ivan: the other thing is more complicated

<ivan> https://lists.w3.org/Archives/Public/public-digipub-ig/2015Jun/0001.html

ivan: I sent an email a few hours ago, early in the U.S. morning
... we have a separate issue in fragmentation, but the problem is interrelated
... [fragment IDs, unrelated to layout]
... problem is with online vs offline

<tzviya> email discussion: https://lists.w3.org/Archives/Public/public-digipub-ig/2015Jun/0001.html

ivan: if there's no packaging, some of these issues disappear, says brady_duga
... so first question is, do we need a package at all?
... we had part of that question last week
... we had some consensus about needing a package
... we need differentiation between publication as package and on web
... there are deep issues here

tzviya: I've been in meetings all morning, but haven't read the email chain
... I think it needs to be a long discussion
... for purpose of requirements
... a package is necessary; I tried to capture it in first item
... I can break that into two items

[uncomfortable silence]

Jeff_Xu: First time for me at this meeting
... I have question about file size limitation
... even if OS can allow large package
... how to download package efficiently, is that in the scope of our requirements

tzviya: I don't think we want to talk about specific component size limits
... things like that change over time
... if we say a video can only be 1g today
... in a few years the limit may be higher
... we're all in agreement that file size should not be specified

Jeff_Xu: even with size limitations now, can be changed in future
... do we want to provide protocol to download large package separately

brady_duga: I'm on queue for different reasons

tzviya: if anyone has opinions on what we should be telling systems about downloading then please stand up

brady_duga: other than best practices docs, there's not anything we tell people today

Jeff_Xu: maybe it's not in scope
... when we download audio book or comic book it's really large
... can be really slow
... or maybe some other group should talk about this

brady_duga: this is covered by streamable and random access

Jeff_Xu: yes

tzviya: OK

brady_duga: do we need a packaging format? in some sense the answer is yes
... we have one today
... the question is, other than for portablility
... do I need a package if I'm not transferring between people
... if I'm a reading system, I don't think we need a packaging format
... we don't need random access if we're just transferring things between people
... but the reading system does need to support random access, but that could happen with expanded files
... my real comment is, do we need a packaging format for anything other than transferring between entities?

tzviya: more important for identity? So I can point to something in ten years. Maybe it's about archiving

ivan: the whole idea, conceptually, of this epub+web story, is that the two cases you refer to
... I have book downloaded vs I have book on web
... there should be no difference between these two situations
... if book is completely online, then I agree for that purpose you don't need packaging
... in the sense of a zip or tar on a disk
... distinguish between physical packaging and logical entity
... the logical entity is a collection of files which together make a publication
... a "virtual package"
... we need to have a URI
... the discussion I started is around that
... I would like to see a URI for the package, and for each of the constituents, whether the package is virtual or not
... and I'm not sure what that is
... how that translates into the requirements, I'm not sure

brady_duga: the idea of this uri that's the same for server vs download, not sure how that works
... are you envisioning the uris are the same?

ivan: the identification will be the same

brady_duga: in one case I have authority in my url, in one I don't

ivan: [crickets] :)
... not sure what is possible
... if one chapter refers to another, it should not be a problem with relative URIs
... if I use annotations, and I want them to work online and offline, not sure how to solve that
... what URI do I use for annotation?

brady_duga: your first example is not in requirements
... on the 2nd case, I don't know how you solve that either

tzviya: let's make that a requirement, even though I tried not to make the impossible a requirement

brady_duga: this is already handled by OCF, require everything to be relative URLs

[discussion of exact language of new requirement]

<brady_duga> Sorry, my call dropped

tzviya: links remain stable whether publication is online or offline
... this seems more of an identifier requirement
... but they are linked

TimCole: it's part of the annotation problem
... do we envision that a package can be served at multiple places
... get chapter 1 from server A, get chapter 2 from server B
... in which case the relative URIs get very complex

tzviya: I did add this as functional requirement

<tzviya> https://www.w3.org/dpub/IG/wiki/Functional_Requirements#Functional_Requirements_for_Packaging_Spec

tzviya: it's good there's a heated discussion
... please take a look at the doc
... the goal is to get a list together in the next few weeks

dauwhe: will post interesting links from public-web-perf mailing list on their review of packaging

tzviya: anything for next week?
... might be education or outreach or identifiers

Heather: I think identifiers

tzviya: we have four minutes
... any last comments?

[explosions]

tzviya: thanks everyone

[beeping]

<HeatherF> *LOL*