See also: IRC log
<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/WebExall: 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
<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
<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.
<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*