See also: IRC log
<inserted> Tzviya's Packaging slides
Tzviya: There are a lot of slides, we are
looking for feedback from you today
... You have heard us talk a lot about packaging
... what is it?
[slide 2]
[Tzviya reads definition]
Tzviya: packaging mechanisms offer
efficiencies and improved user interface
... I put together basic criteria and would like feedback
Deb: You did not include streamability
Tzviya: yes, that's right
[slide 3]
Tzviya: these are the requirements I put together and curious to know if I left anything out
Deborah mentioned streamability which I used to think was part of it, but not
Nick: How does a package feel about being
incomplete
... should it be complete to be considered; someone extracts someone
from EPUB
... so open file, and not there
Bill: set of minimum requirements?
Tzviya: Scope statement?
Nick: yes, basic file points to OPF
... declared it should be within this package so then it's not complete
Tzviya: either a manifest or @ being missing
Nick: anything required by reader system or has been defined by those required files; two tiers
Tzviya: What is the purpose of having an
incomplete package?
... perhaps not having a complete book, but I have defined my table of
contents
... i don't see much value, but maybe someone has another perspective
Ralph: what UA does is up to the agent
Dave: one and two look more important than 3 and 4
Brady: are these a basic criteria for what
you laid out in your definition?
... Is is fundamentally required?
... which parts require access to components without transversing the
entire package
Markus: This is not a complete list of
functional requirements
... to Nick's question about completeness is Nick's question about
digital signatures
... We have listed that in OCF functionality
... ability of package to have static location to find a digital
signature
... and encryption
... those could also qualify as critieria
... At end of day, we need a complete list of functional requirements
Tzviya: yes, and if someone wants to help putting this together
Brady: depends upon...not sure who we are
writing this new package for
... what do we need to do with packaging
Deborah: I would like to speak to 3 and 4
not being fundamental
... if the list is 'let's see what a package is' then I'm ok;
... but if we are looking to create a list of requirements
... why can't we say a packaging format is like old school writing to a
tape archive
... But it's 2015, so we should write a complete list of functional
requirements and make them good ones
<Ralph> Tzviya's Packaging slides
Tzviya: We are pretty comfortable with these
requirements
... But if we write packaging spec differently, the packaging writes it
in
... talking about books, not so much; not books, becomes more of an
issue
... So we should put together a list of functional requirements
... We have zip and derivatives
... Multipart MIME and similar
... and Databasing which we are not looking at today [slide4]
[slide 5]
scribe: Zip
... Thought we might look at Zip and see whether this works; what it
does and does not meet
... and EPUB1 on radar
... Going back to what Zip actually is; and thank you, Brady for
pointing me in right direction
... Zip is pretty stable
[reads from slide]
Brady: If Zip is local, you can jump to
where you want to be
... but if streaming you have to wait for the last chunk
... you cannot do anything until you get it
... If you have it local, you can jump and it tells you where to go
Tzviya: if you have file online
Brady: If you want to display contents of
Zip before it downloads
... and you don't want to wait, you cannot
... have to wait until chapter 50 is downloaded before you can read
chapter one
... if you have downloaded, you are fine
... but there is issue of waiting if not already downloaded
Tzviya: Spec is from the '90s
... talks about splitting files on floppy disks
... has very little attention to metadata in the spec
... it is possible to include more but it requires changes
Nick: I know zip is great at compressing
text
... but for files out of hand, is there room for compression
... is Zip the right package, or is that a nice benefit to reduce disk
size
Tzviya: I have not yet addressed
... outside of Zip, packaging allows any type of compression
Nick: I am not fully functional in Tar
Heather: I was thinking about compression
and wondering about compression format
... several things could come into this and wonder if they would be
separate or part of the packaging itself
... Compression is one thing that would make things tidier with space
... expectations with DRM
Markus: As all of you know, EPUB uses Zip;
has defined OCF spec on top of Zip
... which adds specialized features
... which were deemed as necessary
... there is a file on the wiki
... which lists the things
<mgylling> https://www.w3.org/dpub/IG/wiki/OCF_Functionality
Markus: that OCF does on top of Zip
... The thinking is that when we create this list for the future of
packaging for publications
... we should be able to harvest some things from OCF
... does not mean we need to recreate all the things OCF does
... but owe it to ask what is relevant
... OCF does add a certain amount of predicatbility for entry files
... hooks for digital signatures and encryption information
... two things that are needed
... Then as Brady said, we don't use the built-in zip things
... don't know origins of that
... that is where we are
Tzviya: All of these things are important
and there needs to be a place for them to live
... need to have a home for them
Charles: metadata for us inside the zip container...discoverability means you have to download everything
Tzviya: We should outline criteria
... and what we can do with packaging on the web
... EPUB is a customization of Zip
... we are all fairly familiar with it
[slide 6]
scribe: Robust metadata
... whether this meets criteria we have outlined, do we think robust
metadata?
Bill: I vote yes
Tzviya: does robust metadata meet the
criteria for a package
... I would say yes, but, it's not exposed; it's in the package
... the way EPUB is now, it is not using the language of the web
Bill: the latter is relevant; former is...an access issue
Brady: does offline great
... maybe two entires; online and offline
Bill: it's not because we are saying it's both
Nick: The unzipped EPUB does wonderful on
the web
... does fine with a little code; it's that package part
Tzviya: The package is the problem not the stuff inside of it
Nick: exactly
Brady: you had choices on slide: zip, MIME,
another option is None
... do we need a package file?
... I understand the cases; you are giving me a file
... and FTP-ing it
... but for a web app, I don't care
Ivan: this question comes up the same way in
some of the working groups
... if we say at the moment, the information I got
... that digital publishing is one of the use cases that the WebApp
community looks at
... and they need packaging
... and if we say, 'no we don't' the situation should change
Nick: one of the huge values of package lets
you define a constraint and put a hash value
... on web you cannot forget security
... on the web
... someone will add or remove items that should not be there
... packaging could give us the opportunity to check things
... huge value for that
Brady: I don't believe you gave us the
criteria
... we already said random access
Dave: I read NYTimes web site; it's not
packaged discretely
... don't we have web mechanisms
... publishers probably like packaging; we can also wrap DRM; but is
that required to do what we do
Charles: I was going to bring up security
issue as well
... to know that something has not been changed is huge
Bill: not sure if we are talking packaging
on the web, EPUB or EPUB/Web
... intriguing to say it's what's in the package; agnostic
... as soon as you get stuff out of package, it's fine online
... why is there only one way to put it into a package?
Tzviya: Then use HTML
Bill: packaging offline, or web online
... is it really in a package online?
Tzviya: We are used to package being in a box; maybe it's just a special URL
Bill: and you can put it in a zip
Deborah: balance some aspirational and
pragmatic
... my job is to take things publishers give me and put them on the web
... if we say just use whatever packaging format works
... it's too hard
... publishing industry is not as tech savvy
... we run EPUB check and single packaging
... not DRM or signature
... but a few things for containers; but don't say just give me some
stuff
... industry will collapse
... we are not as an industry good enough to say just give me some HTML
... So I would really like...
Tzviya: We are in the abstract
Patrick: the zip package is not just a
container, but also tied to what you are showing
... good to show pages
... but if trying to make an offline reader with DRM
... the package is tightly integrated to features and how to do well
... cannot just leave it wide open
... you cannot make a reading system that will do it well
... Looking at manifest of XML of the open container
... and it's encrypted this or that way
... file size is in the zip container
... you have to make predictability around retrieving assets, that is
essential information
Paul: Just raise kinds of points people have
been speaking to
... what is the purpose of the package
... security has been mentioned; defining what is there for consistency
in reading systems
... if not through a packaging system, what are the alternatives?
Charles: If you have all the components with
security tags
... for each file, then you know the manifest, if correct, you can check
those without a package having security
Nick: back to practical a bit
... Amazon decided it did not like EPUB spec
... they made that decision
... there is a new spec that no one else can do
... some publishers run it through the mobi generation
... it outputs the format you want
... that is acceptable to many publishers
... also question of are we making business decisions
... if you make this web page with root metadata and then let retailers
decide
... not saying it's the grand ideal
... but it's what certain retailers will do; they will ignore your spec
... then content producers will do what they want
Tzviya: we cannot talk about business
requirements to that extent
... in a discussion like this
... cannot let this cloud our judgment
Bill: Reminder that in the EPUB we have a
package file
... not what we are talking about
... in the package we are talking about
Tzviya: we have a lot more to talk about
[slide 7]
scribe: Allows for the inclusion of non-ASCII content in messages
[reads slide]
[slide 8] http://w3c.github.io/dpub/PackageDPUBF2F/index.html?full#8
scribe: This was 1999; world was not ready
for it
... We have read through this and talked about it
... it offered offine and online support; access to components
... refresh new components
... use information offered on a standard web site
... we were pretty much there on how to access and update the
information
... maybe try it again
Bill: party like it's 1999?
Tzviya: Good job, Brady. Ten years too
early!
... moving to packaging on the web
[slide 9]
http://w3c.github.io/dpub/PackageDPUBF2F/index.html?full#9
scribe: hope everyone read the specs and Ivan's notes
[reads slide]
Tzviya: that is a really long specification
in one slide
... Ivan had written some notes to summarize this and we have discussed
this several times
Tzviya: I would like to talk about what we
would like to see to meet our requiremetns
... I started a Google doc to talk about our functional requirements
<tzviya> https://docs.google.com/document/d/17OC8AXCwzwP1Hl754_vL5nJZBlhZ0vBDcsSStOJ5OeY/edit?usp=sharing
Tzviya: So, tell me some functional requirements
Ivan: I am not sure if everyone is aware of
the situation about this and why we need to discuss this
... Brady and I already had a discussion on this
<Ralph> [Liisa arrives]
Ivan: I chatted with Dan Appelquist within
W3C who works on this
... This packaging document came about not for digital publishing
... digital publishing came in as a use case
... but more about web apps being distributed easily on the web
... this is being done in the WebApps WG
... a document was produced by Jenni Tennison
... at the moment it is stalled
... because of fundamental question
... of whether web or browser community needs such a specification
... What I must admit that I did not understand a few months ago
... put more time into it
... and got a level of understanding
... there is a parallel effort going on
... with Web Workers and Web @
... getting a lot of attention in the browser world
... some predict this will fundamentally change how browsers work
... Browsers will have ability to locally store content offline
... and higher level browser user
... refer to some references, the browser will have the possibility to
go back to the cache
... this cache and mechanism around it is running in true parallel way
to the browser and it does not slow things down
Ivan: There are voices that say...packaing
... everyone can be happy
... there is the question if a web packaging or not is necessary
... where it hits these kinds of issues
... This is the moment when this community says yeah or ney
... what Deborah said, there is a whole industry that lives and dies
with packaging
... some may say we don't care; you define it
... that can also happen
... this is all completely open
... but why it's important for us to put a stake in the ground
... and what Brady asked Yves
... we have what we have; the EPUB package for reason of packaging, so
don't mess with that
... point where we have to make a stand
Brady: I think the packaging for webapps and
service workers alternative
... reasonable consideration
... no one writes a webapp for an unrelated service
... It's not that we don't have a client that doesn't know about the
server
... if you have a client that does not know, you need a defined
mechanism...to know what data looks like
... Web service workers lets you know on the fly...like give me
resources for chapter 12
... give me the right data at the right time
Brady: Give us...a blob of data so you can
do something meaningful
... works well for publishers who know how to make a book work
... not a link to the first chapter only; that would be a mess; but it's
a packaged file for the whole book
... and zip works well for that
... is there a use case for a defined format
... that works in the web app case
... I have e-reader clients and services
... Use Apple reader with someone else's services
... we need to define in that case
... but if talking about individual person creating both sides of this,
then service workers works in that case
... service worker does that
... if it works for web apps, it works for books, unless client and
server are provided by different people
... then we can do it offline and online
... for the web case, service workers solves our problem just as well
... and we should probably go the way the rest of the web is going
Bill: that is the timing question I was
going to ask
... Packaging question has stalled
... service workers ...has traction
... there is a timing issue here
... it could be if the need for this is a publication issue, not a web
issue, then maybe EPUB needs a packaging spec
Dianne Kennedy: representing magazine publishing
Dianne: they want single content to
distribute to channels of content
... like videos
... we desperately need a packaged format, but more like the EPUB case
NicK: thinking about it, no matter how you
have it, there is always a package
... directory has a table
... no matter what, question becomes what is the best package
... hearing a package is more useful offline
... but HTML you still need to define files that are offline or live and
define what to be replaced
... Twitter chat; just offline and don't show this
... Question is what is the best package for this
NicK: rescinding my earlier comment, no need for no package
Tzviya: we have a few minutes left
... We have to keep non-books in mind
... non-books, journals also annotations are very much in this model
... is that annotation part of this package or not?
... We just need to be aware of that
... we don't have time to list the functional requirements today, but
next Monday, please come prepared to list your requirements
George: Learning management systems and universities creating content fit into more of authoring environment that the package needs to fulfill as well
Ivan: To answer what Bill asked
... yes, there is traction around web workers and service workers
... Around Chrome and Firefox, it's either alive by default or you set
some flag
... and it's already there
... I do not knows what Safari does; don't know what MS does
... core spec comes from Google
... Firefox has figured it out
... not a question of whether but when web workers and service workers
will be part of browsers
... On the packaging part there has been reason here why we need
packaging
... as a half-way metadata person
... the need for clear identification for that stuff is important
... I need a URI for something
... we don't have that pointer
... that is an abstract reason why we need packaging
... It may come back this evening for the chartering discussion
... The general browser world may say they don't need a packaging
standard
... But we may have to do it ourselves
... and decide whether IDPF or W3C
Markus: Will not be browser native
Ivan: Correct
... understanding service workers
... if web packaging standard is defined
... and if service worker is properly defined
<dauwhe> status of Service Worker in browsers: https://jakearchibald.github.io/isserviceworkerready/
Ivan: then implementing package by a service
worker is a doable job
... not sure we would lose so much by it being done by a third party
... Brady, you may have another opinion
Patrick: Following lead of caching,
portability becomes important
... I cannot send cached web page to a friend...or to a credit card with
a book
... EPUB, a book is a thing, not a place
... part where we get books with URLs and URIs, it's nice that people
think about books as a thing
Johannes: You mean in JS
... you need a standard...based on JS, all wanting to read the same
packaging file
... You are saying you can do the whole thing in JS
... JS could read spec
... and use service workers to access these things
... For that you would not need a standard for just one JS
... but if you have several and want them to read the same type of file
Johannes: so does there need to be several?
Ivan: Distributing to many readers
Tzviya: but not just about distribution
Liisa: We are not always online all the time
Brady: interesting point about portability
... caching is performancing saving step
... as a user I may want to download book or collection of journals
... and know I have downloaded it to my hard drive and know I can read
it on another device
Markus: that fundamental principal needs to call that out
<astearns> two naive ideas: Could a local zip package be something a service worker could access and fill the cache with? And/or could there be a simple local server with a single purpose of serving local package contents?
Markus: We need to explain the network
independent artifact
... not bound to a browser cache
... an entity that stands on its own
... something I need to explain to people
<Zakim> dkaplan3_, you wanted to ask if we will talk about streaming
Markus: we need a good little essay somewhere on the wiki that we can point people to
Deborah: I wonder if we are going to have the streamability conversation?
Nick: The concept of a URI as an identifier
scares me
... I just had some domains expire
... I still have the data
Ivan: URIs and URLs are not the same
Nick: But having a package and an identifier
pointing to it
... having a package makes the contents inside it easier
<Ralph> Karen: we're also seeing many other devices
<Ralph> ... e.g. devices in vehicles
<Ralph> ... televisions and other devices that provide a reading experience
Ralph: other files
... and what this entity is
... important that we describe the collection of things we are licensing
... this set of things has this license, this signature
... know it's different from that; and whether transportable in one
communication or not
... those are separate
... Markus made a good point
... and we can come back to question of how we transport this
Liisa; one other note
Liisa: one of short-comings of packaging
format is the size
... you cannot zip more than 2 gig
... as we talk about learning objects, long text and collections of
things
... it is becoming a problem
... 2 gigs is a zip restriction
... certain retailers won't let you get beyond 700 megs
Tzviya: A valid point
Markus: It's a requirement
... a 32 bit problem?
Brady: I thought it was 64
Tzviya: We don't need to assess it today
... Streamabilty
... I also had streamability as one of my top criteria
... but conclusion I reached
... is that it's not nec streamability is the requirement but the
ability to refresh a component, like chapt. 12
Bill: question
... an important variant is adding a component
Tzviya; yes, additions, deletions or updates
scribe: that is the conclusion I came to
... streaming does not seem as important if you have random access
Brady: I don't want to have to stream chapter 20 and not redo all the streaming
Deborah: do you want random access?
Brady: streaming all the way to the end
Deborah: we containerize
Nick: not look at it as a large file; 1 gig video
Brady: Depends upon who you are
... I can easily stream video
... but I can imagine a company that does not want to do streaming video
Tzviya: I don't think streaming video should be part of packaging
Ralph: there are two different things
... a question of whether I can randomly access; a communications
question
... even a big video file lets me start at frame number five
... but that is different from another streamability question; do I need
to wait for the last octet before I can start rendering the first
chapter in my request
... that is important to movies, and also important to eBooks
... streamability connotes those two things and some others
Brady: that is a good point about a large
chapter
... you cannot start it until you download it
... today you cannot do it with a large chapter
Ivan: We are also talking about a format for
scientific articles
... now and in future in a packaged format
... will include experimental data
... huge pieces of data
Bill: and will include videos
Ivan: that, too
... and loads of people will make it more optimal
... huge CSV files, which are part of the scientific output for the
article
... then streaming becomes important
... Those big pieces of data are what the researcher will play with once
he or she understands the paper
Deborah: Let's say we are talking abut
widgets
... you can get random access to sections of package; sections pointed
out in metadata
... line 49 or minute 73
... then you are in a section
... can you see beginning of section if the widgets are huge
... i think we are saying yes
... but it's going to take a while
Ralph: as a reader I want that
Rick: the market expects it
Charles: with steamability, video is one
thing, but audio books
... and closed captioning and sign language we need to consider
Nick: does it have to be either or
... can it be spec in the manifest
... do I allow reading system to open before download is complete
... some say it has to be downloaded from start to finish
... some reading systems may want to cater
Ivan: but we said that zip cannot do that
Ivan: you have to take the whole thing
... that is the problem
Nick: If we have random access
... then from that point it's not an issue
Brady: zip can random access if you have the
file local
... from streaming perspective
Rick: it's not the reading system, it's the
content author
... do I let you read it or go online
Ralph: in following on from Rick
... while the author may have choices, we should provide advice to
authors
... a way to put those resources in the right order
... so you get the critical things you need to put in the right order
... This was a good discussion
... Next week we need to communicate a functional requirements document
... and communicate this back to the TAG
... our next step is to put together the functional requiremetns
... so this is homework
... Some of us will need to put together a formal note
... with our thoughts from where packaging goes from a digital
publishing perspective
Johannes WIlm; for Vivliostyle
scribe: we are working in JS space
Julie Morris, BISG
scribe: non-profit trade association doing standards and research operating on behalf of publishing
Liisa McCloy Kelley, Penguin Random House
Dianne Kennedy, IDEAlliance
Dianne: we focus on everything from print
and postal distribution
... to the distribution of periodical content
... not only in print but across wide platforms, magazines and
associated advertising
<Bill_Kasdorf> https://www.w3.org/dpub/IG/wiki/Task_Forces/identifiers
Markus: "The next section is identifiers -
we have until 12"
...This is another of the core problem areas that we see moving into the
future. Identification and linking today in the digital publishing
landscape is "totaly broken" to "almost working
... In terms of simulating digital publishing in how the web works, in
this area we have lots of work to do in here. Bill will be telling us
which items we are tackling first.
Bill: "My assigned agenda is to talk about
fragment identifier requirements. To put it in context, a couple months
ago, we realized we had IDs for publication, and IDs for fragments"
...: "IDs for the publication are a 'losing battle' so lets start with
IDs of fragments."
... "In the context of this group, the "thing" is a publication.
Obviously we have to have a way of identifying that we have a thing. IDs
are a proxy for metadata. "
... "What we are talking about today is how we identify the things that
are in that thing. Not just the descrete components but the things
within those components. Not just the DOM but also a video and
time-based locations. In an SVG a shape-based location."
... "A discussion on the list recently is people have to break out of
their paradigms. People have been defining co-ordinates for referencing
images, but not all images are rectangular and scaling can be an issue."
... "A location that has markup in a textual document isn't the only
thing we need to identify."
... "There is also a confusion on the assumption that there is that
markup that an identifier points to a LOCATION - but it's possible to
point to a fragment, which has a beginning and end point, so it's not a
location as it is two locations."
... "A fragment isn't always a point identifier..."
... "The task we started on was fragment identifiers. THere were many
contributions on the wiki. ideally our task at hand is to dicuss the
requirements for the fragment identifiers. Another item on our agenda is
to look at two of the candidate identifiers."
<mgylling> https://www.w3.org/dpub/IG/wiki/Task_Forces/identifiers#Requirements
Bill: "On the wiki we identified a bunch of candidate fragment
identifiers that are out there."
... "So in terms of the requirements themselves, the starting point
really is this set of 5 that Ivan contributed a month ago when we were
actively reviewing these candidate specs, CFi that is part of the epub
spec, the media fragments that are part of the web."
... "1) Must be able to point to a thing 2) be able to follow a path 3)
a way to reuse externally defined specifications - not just 1 way to
point to a fragment. How you point to an HTML document isn't always how
you point to an SVG or video. 4) Fragments should have conceptual
equivalents to URIs so that they are addressable on the web. 5) Based on
technologies that are widely deployed on the web.
...: "Probably a month before that Tzviya had
contributed a list of 'requirements' that she 'didn't make up' from the
hypothesis wiki. A list of conceptual requirements. Simple, built with
eye towards future, implementable now, web-content is 'unstable' anchors
can never be known for certain so fall-backs, how to fail gracefully, "
... "Hypothes.is is an annotations service."
... "Not expensive to compute. Function well for diversity of content
and formats. Allow you to see if a given anchor will give excessive
bandwidth."
... "Persistent citability. Point-in-time citability - at what point in
time were you referring to this thing. (versioning). Reproducability -
whether it can be shared. Analog for dpub is that it doesn't modify the
resource.""
... "Simple plain english: should it enable addressing arbitrary
locations within a textual document, not just nodes in a document.
Enable discontinuous fragments to be associated in a document."
... "Potentially a fragment ID that identifies a collection of
fragments"
... "ability to mark from 2 locations - start and end."
ivan: "Several things. I'll repeat some of
what you said, just with more emphasis. Whatever we do, we should have
somewhere a big poster "DO NOT REINVENT THE WHEEL""
...: "For various media types, the community has/is defining all types
of identifier types. We want to use all of them and avoid redefining
these where there is already a fragment ID. The number of IDs is
probably stageringly high."
... "The reason I was clearly influenced in those 5 points by the
packaging document is that very clearly they make a consicous attempt to
do just that - reinventing the wheel. it is something we need to keep in
mind. What they do is, a fragment within a package has two sides. You
ahve to indentify things that are package specific."
... "One you have that you have to say - this is the fragment I used and
this is the media type. For the rest, it says "go check out the
identifier for more info" There may be more items - such as the
discontinued things - where there are not already fragment identifiers -
but the fundamental principals is that - in things such as SVG, is that
there are already identifiers for them."
Bill: "People will also USE the existing IDs."
Ivan: "If I look at it through the packaging
lens, or the fragment pointing directly to a URI."
...: "The user should not see a difference that things will not look
differently to the reader if on the web or not. If I make
cross-reference within the package, and it's within the package, then it
all works out. If I do annotation to chapter 1 as an outsider, then I'm
not exactly sure how we would take that, Somehow we should address - and
I don't know how."
Bill: "I have a corollary to add to that. An item in that chapter may point to the SVG. In an epub, you can get to the SVG from the manifest, but in HTML you need to get to the image directly. And you'll use a different syntax for identifying the SVG than a text-component of an HTML file."
Ivan: "The 3rd thing is the timing issue. I
don't know how widespread it is, but there is a specification out there
'memento' that is done by some guys which tries to give a general way of
how you refer to a document on the web with timestamps on it. For that
to work, servers have to be able to respond to that."
...: "Servers are usually not prepared to handle versioning. There is
work out there, so let's not try to put on our plate more that we can
chew. The whole timing issue - because I'm scared of it - i'd rather put
it out of scope for now."
Bill: "What do we mean by requirements?
Defining the issues or just the issues we wish to address."
...: "So we're not attempting to address ALL possible issues, but just
ones we can actually solve."
Ralph: "It would be helpful for this group
to determine what has already been created out there. What have our
systems implemented?"
...: "What I liked about the hypothesis set is that it's looking for
stuff people have tried to implement. I would encourage us to bring into
the discussion, what has actually been built."
Bill: "There are sectors of the publishing
community where there are mechanisms for time-based identifiers. There
is now a standardized way of determining version of record. In that
world, those people would like to be able to use that."
...: "There are sectors where time-based aren't just a nice-to-have but
a need-to-have. We are agnostic as to the existing specifications but
the requirement is that we enable them to be used if they exist."
Tzviya: "Timestamp isn't about versions. Version requirements aren't tied to a timestamp, it's tied to a versioning. "
Bill: "We can't make magazines do it the way scholarly publishing does it."
Tzviya: "Right now, if you start searching for fragment identifiers, you'll get TOO many options. There are lot of dated versions that are on their way out that we want to make sure we ignore. We want to look forward and look at the emerging IDs and flag the opportunistic ones."
"In the magazine world, there's the concept of an expiration date."
Markus: "Tzviya said what I wanted to say -
we need to understand how to go forward without it being a completely
academic exercise. There's an enormous amount of ID baggage out there.
There's no point of listing those. From a pragmatic perspective we need
to understand which are the core requirements that we need to fulfill."
...: "for example, the ID of a range of text - the fact that you can't
do that with a standard URL is really wierd. It's probably because when
you're reading a site about kitten,s, you don't need to, but it's a
problem that we may have to invent. There's probably a dozen
specifications out there suggesting a way to do this, but they may all
be old/deprecated. "
...: "Somehow we need to have a 'must have' 'should
have' and 'nice to have' categorization, so we don't over-populate the
must-haves. Start with the fundamentals."
... "Just like with packaging - we need a very clear, well-organized
document that lets us know what we really need to do.""
Bill: "Devil in the details. One thing we were going to look at is CFI. CFI lets you traverse to points in the text, but we're bumping into an issue of "how do you count characters?" At the last molecule, it becomes extremely difficult."
Ivan: "We want to pare the list down into what are the true requirements."
Nick: I wanted to point out
...not sure if EPUB thing
...but Amazon and iBooks support a versioning system
..already built int
Bill: "That's what I wanted to do. Go
through the document and fix things."
... "When it comes to the epub spec, to be agnostic, you need to be able
to identify into all different specs and then go within the package."
...: "With epub - if you want to specify a term, and it's an ONIX term,
you should be able to identify the identifier as well as the identity
itself
... "If you're in the SVG, is it obvious that the identifier is specific
for SVG."
Markus: "In an ideal world, the MIME type would be used to explain how to utilize the identifier."
bill: "If there was some link to the
cross-mark or cross-ref ..."
... "rather than saying any possible scheme can be put into the
identifiers issues, the ones that are implied by the mimetype are the
ones that we need to focus on?"
Markus: "we should have a view of what identifiers are in use that we can leverage."
Ralph: "Again, lets distinguish between the
identifiers and the mechanisms for using it. It came up previous, an
open-ended problem is an issue because it makes it hard for a reading
system to figure it out. Does the container give me enough information
that I need to write a renderer for that particular container?"
...: "At least the container provides me enough information to figure
out what to do with it."
Lisa: "One of the things i think is fundamental - the authors VS externally - any random user calling something a fragment. There is a bit of worry in that any random user does not know anything of what is inside the document itself. They maybe can place markers, highlight something, but what they are not necessarily going to get is the relations
hips of something within. The image has copyright and credit that need to be attributed to that image. We don't have good ways to move that with a potential fragment."
Bill: "All of that is very important, but
for this initiative - the goal is "how to identify the fragment" Once
you ID it, then you can build systems to identify the fragment."
... "we're focus on how to identify. It is both internal and external
identifier."
Ivan: "The point you noted has an issue with an identifier and the metadata linked to all of it. A fragment composed of discontiguous things."
Charles: "How big can a fragment be?"
bill: "fundamentally we're saying that there is a publication that some of which can be."
"How big can the identifier can be? How big can the identified content be?"
bill: "our task isn't what you can do with a fragment, but what you can do with it."
<Ralph> [Mia arrives on the phone]
<Ralph> Nick: without a package it's difficult to have a multi-page fragment
<Ralph> ... e.g. you can't specify simply start and end page since there are pages in the middle
<Ralph> Bill: perhaps there is a fundamental requirement that a fragment identifies contiguous data
<Ralph> Liisa: [some requirements would] assume a linear reading order
Nick: "Does a fragment need to be contiguous"
Bill: "I assume people are familiar with CFI. When he developed that list of 5 requirements, he said: 'lets take a look at these 2 potential specs, and lets see how well they fit these requirements."
<Ralph> Proposed Strategy
Bill: "CFI has a way to identify the things
within the package."
...: "Has the ability to step-through to find it's item."
... "As far is Ivan knows, it cannot identify down to the character."
Ivan: "My point for that is that it's intimately defined on EPUB and xml and the current format of the manifest."
Bill: "Getting to Markus's earlier point. If
you have an epub, and you want to find a location within a textual item,
CFI is a good solution. Could it suffice - no - it doesn't meet enough
of our requirements."
...: "PFRag - cannot traverse the document? Maybe - if you use the
fragment identifier appropriate to the mimetype, it lets you get inside
the document."
... "Should have a way to externally define fragment id sections. Hands
off the task of further fragment to another ID scheme that is
appropriate to the MIMEtype"
Markus: "What's the end-point we want to get to?"
Bill: "I wanted to see if these 2 candidate specs let us get to where we want to?"
Markus: "I keep ending up saying "it really
doesn't matter" What we really need is the fundamental pointing
mechanisms. If we select PFRag, it won't really matter as they won't be
able to use the fragments."
...: "Define requirements, look for gaps, and find the identifiers that
fit already based on mimetypes... We have to begin with the actual
functional means. All else is an exercise for later."
Bill: "This gets to the 2 most important with hypothesis today. We can't build it based off the future spec, but we better not be building something that we expect to be built today that doesn't work.
Rick: "One of the things we love about CFI is that if you assert an ID on an XML, if the CFI isn't valid - is that covered in this?"
Tzviya: "It's part of the fail gracefully"
Markus: "Please explain"
Rick: "If you have an ID attached to an XML. Editor comes in, creates a new version is created, but the CFI can still re-resolve the ID, despite it's new location."
Markus: "Does that sound like marching orders - to list the fundamental requirements. We have to attack the fundamental requirements. The syntax is secondary."
Ivan: "For me personally, the issue isn't
the identifier, it's the duality of identification - whether part of the
package is "part of the package" or it's on the web as an HTML file.
It's what worries me the most. If I'm in chapter 1 in a book, which is
package. The book has an identifier..."
...: "Both CFI or the package identifier would identify chapter 1 is a
very specific mechanism - starts with the package, goes to chap 1. If
the same book, part of the web - then the natural way of identifying the
part is HTML. So now there are two different ways to get to the same
package. That worries me the most. How do we manage the duality
of offline VS offline?"
...: "compared to that, the rest of the items is important, but minor.
And I'm not sure what's the best way of doing that. How the various
cross-references within the book... What happens if I make an annotation
of a book/chapter while on the web, then go into offline mode?"
Bill: "Starting with the fragment identifier sounded like a good idea, but it's so dependent on the package and it's ID, that we can't focus on it."
Ivan: "In one of the states, the way it's done is relied on a fragment ID. "
Bill: "wouldn't you want it to use the same mechanism?"
Ivan: "We have to be careful of terminology,
it's on the web, it's a "url" and not a fragment ID."
...: "If it's on the web, and it gets to chapter 2 - it has a fragment
id. What i'm looking for now is a fragment ID."
Ivan: "we're disagreeing on terminology.
When I say "fragment" i'm using the specification term - which is in the
URL spec. To the outside world - to the web world - if the chapter is on
the web, I do no use a 'fragment'"
... "It's identification is not after the hash-mark."
<tzviya> URL spec: http://www.w3.org/Addressing/URL/url-spec.txt
<tzviya> URL WHAT WG: https://url.spec.whatwg.org/
Ivan: "I don't know how to use this whole thing and rectify."
<Karen> Nick: what is wrong with having the identifier live in the fragment
<Karen> ...like my URL...and the fragment identifier goes into the package and does the appropriate things
<Karen> ...is there a reason why we cannot use it?
Ivan: fragments never hit the server on HTTP - so that's what prevent us. "
Ivan: "Think of a scientific publication that has several parts - which has 1 fixed identifier (package). How would you address the 2nd part of this research object. "
Ralph: "I'm thinking that the concept of relative identifiers and absolute identifiers is relevant here and it would help to have some use cases to know the problem Ivan is describing"
Alternate words for "fragment" http://www.thesaurus.com/browse/fragment?s=t
Lisa: "Pointing to an annotation is very difficult, especially since what is on the web is different than the local"
Bill: "Would it be useful to - probably Ivan and Rob..."
Ivan: "The annotation working group works only with things that are strictly on the web. The problem I'm discussing is beyond their concern."
<tzviya> action Bill_kasdorf Create Fragment ID Functional Requirements with must have/should have/may have
<trackbot> Created ACTION-50 - Create fragment id functional requirements with must have/should have/may have [on Bill Kasdorf - due 2015-06-02].
<tzviya> markus: the amount of pain and money that publishers put into styling and pagination is astronomical
<dauwhe> http://www.w3.org/TR/dpub-latinreq/
<tzviya> ...dave has been working on pagination and latinreq
Markus: "We've had a brave knight sent in - dave kramer - working exclusively on pagination. Describing various aspects of things you can't do with CSS today. Dave's work has been multi-faceted."
<ivan> Pagination Editors' draft
<tzviya> scribenick: tzviya
markus: what are candidates for pagination, what are next steps?
ivan: let's clarify what the requirements of the IG are
dauwhe: my hope is to better understand
current confusion
... there are technical and political issues
... on specification level, if paginating a document, you are slicing it
into pieces that CSS WG calls fragments
... the CSS WG is interested in approaching things at fundamental level
... there is little understanding of how CSS works behind the scenes
... Many CSSers are signatories of extensible web manifesto and enabling
developers to use the building blocks of web themselves
... provide primitives and allow developers to create the polyfills
... thus evolved project Houdini
<dkaplan3_> https://wiki.css-houdini.org/
dauwhe: Houdini TF is joined task force of
TAG and CSS WG to explain the magic of CSS
... goal is to expose the technical functionality of rendering engines
... one of goals is exploring the CSS Box model
... As authors we do not have access to the calculations that go into
the "magic" of calculating what a "page" is
... How do we create measurements to get to a location on a page? Create
APIs to access pages? etc
... This is necessary for pages, regions, multicolumn
... Anything we come up with needs to work with all of these.
... there is a section about overflow as well
brady: essentially 2 specs - what is a page and how to hande the content
Dauwhe: less clear what will happen on
Houdini side
... Houdini will have a F2F in Paris in August
... If we need to polyfill pagination, what primitives would make that
easier?
<astearns> column balancing is a multicol-only feature as well
Johannes: everything has to world in all fragmentation aspects - one correction is that multi-column spans applies ONLY to columns
ivan: my understanding is that Houdini is the solution to solve pagination, but fragmentation and overflow seems to be happening in parallel?
dauwhe: yes. we are approaching from 2 angles. We must build the primitives and we also need define regions, etc
Johannes: my understanding is that interest in print from browsers, etc is lacking, but implementations based on regions etc may be used for columns
<astearns> printing in Safari used to be based on multicol as well
Johannes: which is of interest for browsers (meaning that page is not of interest to browser, but columns, regions are)
brady: these feel like 2 completely separate
things, not 2 approaches to the same things
... one is old method of write a spec and see if it works, Houdini is a
radical change to way CSS is developed
... and it might get more traction
... not convinced that we will get page breaks if we just write a spec
alan: agree with Brady. Houdini is more
likely to come up with useful ways of pagination, but it is only half of
bridge.
... the low level APIs will be informed by the low-level realities that
Houdini will expose
Brady: intent will be to expose pagination spec that exists (not write on their own), hope to have declarative specs that don't get in the way
<dauwhe> http://dev.w3.org/houdini/box-tree-api/
ivan: I agree with Brady. I am quite concerned with time involved. Pagination is one aspect of Houdini, which could take years.
<astearns> s/low level APIS will be/high level APIs will be/
ivan: is Houdini going fast enough for this industry?
Dauwhe: I am more optimistic about Houdini
because the people working on it are the people building the browsers.
If they are working on it, it seems likely to ship
... there is not a lot of activity on list, but it seems like a lot of
research is happening
... we have questions, and they might have answers. Perhaps we need
better communication
Ivan: is there a way to influence the path of Houdini?
Deborah: What are we trying to communicate to them?
Ralph: would it be useful for this TF to ask
Houdini to demo how primitives paginate
... ?
Dauwhe: It would be helpful to ask Peter Linss to show us what he means
Johannes: It would be useful to know if we needed to create a pagination polyfill atop a Houdini polyfill
dauwhe: would also need to know which of
DPUB use cases are met by Houdini polyfills
... and compare Johannes and Readium experiences
<astearns> https://www.w3.org/dpub/IG/wiki/Pagination_Requirements
Nick: do we have a requirements doc for Pagination?
Dauwhe: see Brady's list of pagination requirements
Nick: It would be great to get line by line
annotation from Houdini to see what is supported
... EPUB has mention of page requirements
brady: this stuff is covered in latinreq
alan: the part of Houdini that will address
is the custom layout. We talk about box-tree, but that is a stepping
stone to get to custom layout
... there are other stepping stones as well
... I echo Ivan's concern about how long this will take
... I believe we need to continue working on existing and future
polyfills for pagination
... because I would like to evaluate polyfills vs Houdini because I want
to be able to say about Houdini, here is how we can make it easier
<Zakim> tzviya, you wanted to invite PL to a meeting
<Ralph> Tzviya: seems it might be good to invite someone from Houdini to talk with us
alan: If Houdini does not make it easier, then we've done it wrong
Tzviya: as Nick was saying we have LatinReq
and Brady’s doc, but we need an itemized list of requirements, if
anything missing we fill that in
... then Dave, Alan and Johannes sitting down with members of Houdini to
determine what they are working on now; that could be a taskforce
meeting or whatever. To find out where we are and where we need to go,
ask how we can help
Ivan: to reinforce what you said Tzviya,
feedback I got made me worried, the message was that there are no dpub
related issues in CSS WG, makes me sense that that group is not
conscious that pagination is a central problem
... we will clone dave
... I am sure the CSS WG answer will be that we need to provide the
resources
Brady: does it make sense to attend Houdini meetings without being in CSS WG
Johannes: its not only a matter that print
hasn't been worked on, they are prioritizing what goes into browser.
When you tell them I want something equivalent to a Latex rendering
engine in the browser, they say no.
... need to focus on features that are not print specific
Dave: what matters is what the browsers implement
<astearns> some of the same APIs needed for pagination are also needed for handling basic overflow, which browsers are much more interested in
Tzviya: we talked about putting together use cases, we will need to prioritize.
Dave: whats next? Talking to Houdini.
... we will describe the importance of pagination, ask if they need
functional requirements, ask what primitives might be needed.
Ivan: do you think its worth planning to have someone on their group in some weeks? Dave: we can try. Ivan: there is a sense of urgency here
Dave: if we can start this conversation well before August so we can have something down on the ground at the F2F
Ivan: easy for me to say, but really all the
publishers around this table should try to find people to join the
Houdini WG
... they will push back any new work because they don't have the
manpower
<scribe> ACTION: Dave to email PLinns to start the pagination-in-houdini discussion [recorded in http://www.w3.org/2015/05/26-dpub-minutes.html#action01]
<trackbot> Created ACTION-51 - Email plinns to start the pagination-in-houdini discussion [on Dave Cramer - due 2015-06-02].
Karen: understand that CSS has a lot of things on its plate, is there also someone on TAG that should be involved (beyond Peter)
<astearns> Peter and David are the TAG members most engaged with Houdini
<astearns> (but they're both CSS members as well)
<Ralph> Houdini mail archives
<Ralph> Liisa: the lack of pagination cost e-reader developers
<tzviya> liisa: it is very difficult for publishers to work in existing world because there is limited hyphenation, widow/orphan control
<Ralph> ... but it also costs publishers hugely
<Ralph> ... I have to explain repeatedly that we do not have as much control over the layout as the editors demand
<tzviya> ...i can add page-break information, but the information may be lost because different systems interpret in different ways
<tzviya> nick: there is also processing cost
<tzviya> liisa: every browser engine has to figure out on its own how to intepret things like widows and orphans
<tzviya> paul: take the conversation away from tradtional books and magazines. look at modular content
<tzviya> ...there has to be rich support for standard formats. if we stay framed in ink on paper, etc, we will miss an opportunity
<tzviya> Ivan: we have to spell this out in real detail for browsers. We must draft in real detail what the problems are
<dauwhe> http://www.clickhole.com/blogpost/time-i-spent-commercial-whaling-ship-totally-chang-768
<NickRuffilo> http://usabilitynews.org/the-impact-of-paging-vs-scrolling-on-reading-online-text-passages/
<tzviya> nick: studies about benefits of scrolling vs. page swiping
<NickRuffilo> http://www.nngroup.com/articles/infinite-scrolling/
<NickRuffilo> http://ux.stackexchange.com/questions/33406/infinite-scroll-vs-pagination-in-e-commerce-websites
<clapierre> https://github.com/w3c/dpub-accessibility/blob/gh-pages/Agenda-20150526-dpub~a11y-bisg-collaboration.md
"We all agree that accessibility is important. Let's talk
about collaboration between DPUB and BISG"
...: "What format should the collaboration should take, what should be
the goals of it."
... "DPUB accessibility, BISG accessibility, then what form the collab
will take. "
Robin: "I'm robin from Benetech, and chair of the BISG A11Y work." We have a few cross-over BISG/DPUB groups
Charles: "What we've been doing is looking
at the W3C WCAG techniques and seeing what is relevant to DPUB. Most of
everything was relavent."
...: "We wanted to see what was missing from WCAG that dpub needed and
we found about a dozen of topics that were missing."
... "These will be apendicies for our notes. What are the best
practices, etc. Our next steps are to create this note and fill it out
from our info that's existing or what can be enhanced on from WCAG"
... "Note is at a W3C level."
... "we're just about finished all the specifics, so it's hard to say
whats missing at this point, but we've come up with a few of the more
important issues, and now we'll focus on the note, hopefully done before
end of year."
Ivan: "From practical level/relationship
level, it might be better if we first publish a draft - which isn't
final - then we go to WCAG with that draft and discuss it with them."
... "I know they were involved with that, so they aren't in the dark..."
Deborah: "Yes, we were going to do that."
Ivan: "Jeanne [Spellman] should be involved, as we had the discussion with her."
Deborah: "We've had discussions with her."
<Ralph> Michael Cooper as well
<Ralph> for WCAG
Robin: "We're attempting to demystify
accessibility. For high-level execs. We're clarifying some of the
high-level legal documents"
...: "What you need to know to create an accessible file. George is
helping with that. Hopefully the work George is doing with the baseline
document will give people some baseline. We have phenominal
participation. It brings together lots of interest groups, distributors,
etc. We all find it a rousing meeting. Lots gets discussed. We talk
about how we collaborate with people who are doing what we're doing."
...: "There are so many people who have accessibility initiatives. Tons of documents, lots of stuff going on, so thats why we need specific standards, policies, etc. "
<Rick_Johnson> WIPO's ABC
http://www.accessiblebooksconsortium.org/portal/en/index.html
...: " Top tips will be a critical component of the quick-start guide.
There was an accessibility panel. To warm everyone up, we gave people a
10-tips document to summarize some of the best practices. It caught
fire, AAP, epub3 group... It's grown to 14 tips, but we mainly stick to
the top 10."
... "we're taking that spirit into the quick start guide to make
accessibility accesibility."
Robin: "We got into writing the guide. We gathered a list of existing resources. We discussed with George as well. But all of this will be included in the guide. The question is - how do we work with other organizations who are working on this already. A very basic way we can jump into collaboration is to keep those updates going. It makes sense to include whatever finalized W3C specs/resources in the guide. We're hoping to publish september. "
heather: "Do you intend for this to be global?
Robin: "We'll be doing things global"
Julie: "We are going to focus on the US first, since there are alot of global differences, but we do want to think globally"
Bill: "what do i need to be aware of, and what do I need to know to do it. It's not telling you how to do it. It points you to resources on how to do it. It doesn't provide you with technical stuff that W3C is providing, it's providing the high-level things for business and points to implementation. It's a complimentary resource."
Ivan: "To complement what you said, there is
a separate group at W3C - the education and outreach group - for
accessibility. They do try to collect and write things about
accessibility, with the caveat that there are differences for WCAG for
websites and publications, so there may be a bunch of overlaps."
...: "Contact Sean Henry to find out what they're doing and avoid
overlaps."
Karen: "Sharon Rouche from Mobility is the chair of that group and excited to see accessibility in verticals."
Deborah: "George - give quick pitch of the doc:"
<Karen> http://www.knowbility.org
George: "Publishers have said 'tell me what
I have to do to make my document successful'. Even with top-tips, you
don't know how far you have to go to make your document accessible. It's
becoming more important as we get closer to the americus treaty being
announced."
...: "I've talked to a person who says: 'it's best if the industry
defines the base line for accessibility than the government.' You can't
have BISG or other groups declaring a baseline for anti-trust. Hopefully
we can drive, but not own, a document that is the baseline for
accessibility."
... "There will be a difference between trade and education, and I would
believe that eduPub would be clear about meeting requirements. It would
be an informal agreement. As tools and reading systems improve and
features become feasible/practical/usable I'm hoping we can move things
up at that time. We want to make sure that MathML gets moved up in that
baseline. Support within reading systems is important for that now."
Deborah: " charles protests, I'm going to skip dpub IG taskforce next steps are. I think that if you want to have say in what's next - attend our weekly friday meetings. Or talk to us on the mailing list. Doesn't need to be now."
<ivan> Home page for the Accessibility Education and Outreach WG
Deborah:: "What we can get out of collaboration: One goal we're hoping
from this meeting is everyone from the BISG accessibility and DPUB group
will know what their next thing to do is. One proposal is that our group
can be a good liason between BISG and W3C. "
... "If we say 'hey, a bunch of publishers should know about X, Y, and
Z, we tell the BISG, and vice-versa. One prospective goal is: each
person from BISG says 'i'm going to come up with at least 1
accessibility standard that I know as a whole the publishing industry
doesn't know about or understand."
... "Then W3C can say: 'yeah, there are things we need to do about
this.' A year from now or 6 months from now we can review the
recommendations and figure out what worked and what did not."
<dkaplan3_> DIAGRAM -- http://diagramcenter.org/standards-and-practices/content-model.html
George: "the BISG accessibility group is
fairly new. There's ABC and the DAISY that is putting together
materials. We just need to consolidate and make sure everyone is saying
the same things "
...: "Having a hub that can at least point people in the right
direction. That is hopefully something that will evolve out of all these
activities."
Bill: "Something I'm hearing that resonates is that it wasn't a matter of finding the documentation the W3C had was bad, just that it's written for a technical audience - not very readable by business people. Also found quite a bit of documents that people simply were unaware of."
...: "For example, a primer."Tzviya: "I've been attending the
accessibility task force. It's eye opening. We actually sat down and
picked an idea that we wanted to bring up with authors. The W3C does
actually have an education outreach for accessibility."
...: "Then our taskforce can be a liason taskforce."
Deborah: "The two things: the thing about W3C documentation - it is very great for what it is, and there are starting to be tutorials, but the fact that nearly every organization has a group that has to boil down WCAG, there is clearly a gap. That's the value of having a W3C group. But it's worth a try."
Ivan: "Seriously, this kind of bridging is important. I don't know the details of the document that the group produced. I have read them, but a long time ago. This must be done."
Deborah: "I'll give the examples we came up
with: The authoring tools guidelines 'assist authors with accessible
templates' the success criteria get into the metadata to define if a
document is accessibility."
...: "No one knows that atag existing. on the WAI mailing list, there
was a long conversation 'but we can't do it, it doesn't belong in WCAG'
and they didn't think of using atag."
... "Another example: The ability to do basic text formatting that you
can personally identify what item elements you can allow to change to
allow for text formatting."
Bill: "Question for Julie - I want to know about ALL of those. Although SOME of them are for publishers, some are for reading systems. Is that within the scope of the start guide?"
Julie: "That's a good question - possibly an opportunity"
Ivan: "The history of WCAG VS the other CAGs
is important to realize - and you reflect it here. WCAG has been
extremely successful in places like the EU, where it's gone into
legislative power because it went to the largest constiuency around -
those who produce webpages. So the other two CAGs are much less in the
limelight."
...: "The fact that a bunch of other users aren't aware of this document
isn't just true for publishing."
Deborah: "It's something we might be in the position to help with."
Ivan: "At least for the authoring tool - there was a naive believe that no one would author HTML is notepad... And we all see where that left us!"
Bill: "One aspect of George's doc and the quick-start is 'who can do this for you' so there are resources out there that can handle things for you. Organizations like benetech, etc."
George: "This is all sync with epubtest as well"
Deborah: "Next steps: I would LOVE it if
everyone at this table went home knowing what they're doing next."
...: "are we all happy with the 'liason' role?"
Robin: "I am on the AAP task force, so I can be a join there."
Bill: "Deborah, you were saying the Dpub is W3C way of communicating., but BISG is a way to talk to publishing."
BISG is the high-level items, the technical is referred elsewhere
Julie: "Perhaps there is a group, within BISG that would be good to have a discussion on gap analysis"
Nick: "Where will things live"
Ivan: "Minor practical details. W3C is obsessed with everything being archived. If you can use an e-mail list or something else archived, that would be very useful."
Deborah: We wil continue talking and plan communications around the summit. And we'll be consulting on the documents
Nick: I have lots of slides but will go
through them quickly
... then discussion!
... we've had an awesome time so far... let's solve world hunger!
... this is epubweb buzz
... communication, education, and messaging.
... this is PR
... 3 audiences:
... digipub
... 2. prospective tech members
... 3. prospective business members
... each requires a specific voice
... goal is to keep them separate
... focusing on internal members
... focus on value of membership
... remind on why they're members
... promote more active membership
... positive reinforcement for good behaviour
... for potential members
... explaining how contribution is possible
... to encourage implementation
... letting new app developers learn about a11y, for example
... for prospective business members
... explain how standards organizations work
<Ralph> [Jeff Jaffe arrives]
Nick: it's a black hole
... explaining how a standard works
... explaining how the industry can help shape standards
... how it ultimately comes from a human need
... pagination is not a human need ;)
... these are business requirements
... first step: what w3c does
... documentation, tutorials
... second step is more niche
... conveying message of what is DPUB
... how do those standards work
... constant buzz is the goal
... the biggest issue is that w3c should be as visible as bandaids
... should constantly be out there
... press releases
... if we can do one action item per month
... then you'll be aware
... within a years time most publishers will be aware
... press releases, articles and editorials
... there are only a few journals in publishing
... i'd like to build a relationship with them
... what's going on with a11y, for example
... dbw, publishing perspectives...
... creating bonds so we can get our message out
... blog posts, webinars, web-based presentations
... taking conference slides and putting them up in a central location
... so they can easily be found
... like TED
... human readable documentation and guidelines
... there's a business audience and there's the tech audience
... to start, build a set of executive summaries for the business user
... why it's important to their business
... guidelines on how to build an executive summary
... creating a social media presence
... LinkedIn
... automatically post to various social media destinations
Nick: any one in group should be able to
contribute
... avoiding bottlenecks
... relationship building with media outlets
... human-readable documentation
... high-level conceptual documents
... i.e. executive summaries
... guidelines for technical users
Nick: that's it!
tzviya: thanks nick!
... I'll add a few links
... we all want to do this stuff
<tzviya> https://github.com/w3c/dpub
tzviya: the short minutes, for example, came
out of a request for executive summaries
... here's a repo of our slides
ivan: and ADD TO IT!!!!!
<tzviya> http://www.w3.org/blog/dpub/
tzviya: we have a blog
... that's where the short minutes go
... add to it. write for it!
... if you write for it, tweet about it!
... exec summary is a good idea
... just did that for *CAG documents
ivan: I do that too
Nick: build everything with w3c in mind, so it can all become a broader thing
tzviya: important to have an audience in
mind; Karen has been hard at work on that
... having this be a group effort is important
Nick: having all of these resources on how to write these things--make it easy for people
dkaplan3_: do we have a blog? I didn't know
... do we clear it with someone if we want to post
ivan: if you're in the IG you have write permission
dkaplan3_: do you want us to ask permission?
Karen: maybe for light editiorial touch
<Ralph> [Liam Quin joins by phone]
Karen: I have communication role at w3c
... we can do light editing and advice
dkaplan3_: my second question. There's lots
of us here
... at my workplace, we want to get 1/2 posts/month, can divide up
amongst lots of people
... could queue up posts
... we could do 15 dpub posts in september
Nick: personally, I've started a timeline
for the next year
... when i'd like certain events to occur
... what is that one action item per month, then we can find owners
... we don't have a blog strategy
... if you want to write something, write it.
... but might be complicated with things that should be published by
(digital) journal
tzviya: company blog posts could be reposted
ivan: blog is fine
... people have to know it's there
... I'm more excited about regular entry to DBW or something like that
... that's what I would emphasize
... once they find us there, then they might come to the blog
Nick: I'm assuming we have no mailing list,
no buzz
... first goal is to work with DBW on webinar
Nick: we could get a pretty good showing
with w3c name
... I have connections with most of the journals
... we could do something regularly
... we're a name of authority
ivan: with limited time and energy, we should focus there
jeff: you're asking for content, and a
community to read the content
... we must have a huge mailing list
... we could let them know we're starting to have a discussion
... for content, I'll volunteer to do the June blog
Nick: can I do as press outreach
... if it's Jeff, we can even do something like Forbes
Jeff: for Forbes, I'll need help :)
... we did a nice thing for American Banker
Karen: we've had volunteers for helping with webinars
tzviya: markus and I have lots of presos
ivan: our presos are very technical
Nick: i could write business explanation of technical presentation
tzviya: I've done that too
pbelfanti: it's important to acknowledge
participants/contributors
... if that acknowledgment is public, it helps with their managers, etc.
Nick: that might be a good thing for the blog
ivan: when I do meeting overviews, I chose a
style of not mentioning names
... maybe I should mention names
tzviya: let's try
HeatherF: Who is we? The W3C? DPUB?
Nick: We've been switching a lot. It's
mostly DPUB
... the royal we is W3C
George: Benetech has just put in a grant to
DOE, that will focus on DPUB
... that would be good blog post
tzviya: we have an assignment for june
... we'll put together a plan
... and Nick will write for something like Publishing Perspectives
[switching presenters]
<tzviya> action nruffilo create plan DPUB PR
<trackbot> Created ACTION-52 - Create plan dpub pr [on Nicholas Ruffilo - due 2015-06-02].
mgylling: expires in september
... we've been working on new charter proposal
... Ivan will show a first draft
... we anticipate modifications
... focus on how it differs from our current charter
<Ralph> DRAFT Charter for next DPUB IG
<tzviya> http://w3c.github.io/dpub-charter/index.html
ivan: the current charter was written we
didn't have a clear idea of where we were going
... so it's very general
... this charter does two new things
... 1. It puts epubweb into the picture
... tries to describe work in terms of epubweb
... would look at all the technical issues
... the doc includes extract from white paper
... the important thing is that the group should look at the technical
issues
... perhaps beyond the white paper
... in doing so it's OK for the group to do technical specification
work, but not a standard
... in the course of the work, the group has to identify those tech
features that need standardization and are not covered by existing
working groups
... so we ask w3c to set up a new working group to do that feature
... sortof like the annotation wg
... although that also had a CG
... additional thing
... this group would act as meeting point between rest of w3c and what
happens in IDPF on epub 3.1
... lots of things in draft charter that are related to w3c standards
... it's for two years
... that's the sense of it
ivan: mechanics
... according to our rules and traditions, we will issue advance notice
to AC members, not a formal vote
... might go out this week
... then depends how much work has to be done on this charter
... then we can send out charter for formal vote around the end of june
... we might even be recharter before old one runs out
... but we could also extend old charter if necessary
tzviya: question
... we put lots of epubweb language here
... very tied to epub/idpf
... IDPF is responsible for specs
... w3c is working on foundational stuff
... are we vision holders? Is that what we're supposed to do?
ivan: if there are specific technical
issues, we'll address on case-by-case basis
... whether it should be at idpf or w3c
... for example, web packaging
ivan: the webapps group may decide packaging
isnt interesting
... then we might take it up at DPUB
... or there may be some things where natural home is idpf
jeff: perspective in w3c team
... later are two sections, deliverables and timeline, both of which are
tbd
... when it goes for formal approval, those things are important
... Ivan would want your input on what the deliverables and timelines
are
... to tzviya's point, if the deliverable is a vision of a future and
timeline is 2025, that won't fly
... so we should have some of those conversations now
... a deliverable should be "we expect to analyze manifests"... or
something like that
... or we'll have a task force to do xyz
ivan: can i add one thing
... one major difference between WG and IG
... that difference is enforced strictly
... WG is much more stringent
... in IG it's less stringent
... I could not write charter for EPUBWEB WG because I don't know the
deliverables
clapierre: a couple things
... one: I assume we stay as IG
... two: is there a chance it will be rejected
ivan: we have 400 members, some of whom might object
<Karen> Scribenick: Karen
Ivan: Maybe it's a good idea to emphasize
this point
... that it's continuation of the work
... but if there are items...the DPub area; the Accessibility notes that
have begun will be continued and finalized in the new one
Paul: Back to Tzviya's point on the vision
... will this group be a steering committee?
... Do we make it so...does action happen or does it go to a group and
they say they are not interested
... how much authority do we have?
... Do we spin up a new group for example?
Ivan: I have to ask my bosses:-)
Jeff: If there is a topic that you would
like to persuade and existing WG to do
... like CSS or WebApps
... it's always a negotiation.
... They get more demands than what they can do
... if this steering committee determines that a WG is needed to own a
new piece of technical turf
... assuming that is sensible, you can spin up your own WG
... you would need to have the technical expertise to do it
Paul: if this group articulates well what
the requirements are to create this EPUB/Web format and the deliverables
to be in place for it to work
... what happens to those requirements
Jeff: Let's take an example
... Three years ago the Web and TV IG folks determined that media
streaming needed to be done in HTML5
... so they brought that to that group
... Also saw second screen was important and they started a Community
Group
... that then spun up into a Working Group
... so many options are possible
George: Did they put people into that WG?
Jeff: yes, they did and helped bring new people
Ivan: This IG should be active in setting up
the charter of a new Working Group
... a WG is much more accountable to what is in the charter
... They don't have possibility to say it sounded like a good
idea...otherwise group is out
... This charter has a major influence on new WGs through your vote
... and you have the power to call it
Deborah: more of a comment on this specific
draft
... On Accessibility TF discussions
... Does DigPub mean EPUB?
... Go back and read the EPUB docs?
... no it did not
... But now it looks like we're saying Digital Publishing means EPUB
Tzviya: Need a new name
Ivan: if you look at the white paper, we go out of our way to say it goes beyond electronic books
Deborah: Are we going to say our focus will
be on EPUB/Web to exclusion of other digital publishing technologies
... that other things won't use what we are calling EPUB/Web
Tzviya: We cannot do that
Ivan; we need more than brownie points for a good name
Deborah: not just question of EPUB/Web, but
what DigPub cares about
... Do we care about Time.com and what they put up on HTML; is that
Digital Publishing
... We went into the weeds in the Accessibility Group
Jeff: If you look at what's up there
... is our vision for EPUB/Web
... first visual of the charter is all EPUB/Web
... which is what Deborah is saying; should not be the exclusive topic
Ivan: Yes, I take the point and should not try to solve it
Dave: the mission and the percents
Ivan: many brownie points for new name
Nick: It sounds like we have...this group is
straddling between W3C creating amazing specs for this ideal wonderful
product and we have IDPF creating a very specific format
... to suffice needs of industry to do publishing
... and doing good job to keep the communication going
... Not sure of timeline
... what about communications of liaison and gap analysis
... determine where EPUB is lacking in W3C
... and where W3C is lacking in EPUB
... and from that
... if we cannot convince CSS to do pagination
... then maybe a WG on pagination is necessary
... but determine that it's a gap
... is that a direction to head in?
Ivan: I'm a bit afraid
... the way you formulated it
... sounds like putting EPUB and the rest of W3C
... as an opposite to one another; not what you meant, but the way it
sounds
... it's more a matter of using more the term
... portable documents, a more neutral term
... not like EPUB everywhere
... to get the whole of publishing into the picture
... not this is what is missing from EPUB
Markus: I understand your approach
... but note the items we have called out
... the incongruencies for EPUB/Web
... the gap analysis you are talking about
... is instead the list of items that need work
... i hope we are good on that list
... We may remove or add some from the list
... but we have some clear directions
Ralph: I deferred to Nick
... Paul asked what influence this group has
... under this or some other charter
... The influence we have is related to the previous discussions about
BISG and Accessibility
... and Nick's discussion on the broader community to make sure their
needs are addressed in the specifications
... So part of this group is to 'lobby' requirements say with CSS
... and we may not see their reaction being suitable
... More consistent theme, the more likely our requirements will get the
priority
... Deborah asked another question that I wanted to hear more discussion
... this charter is focused on an important item
... [EPUB/Web vision]
... and while we work on that vision with IDPF
... Does it make sense to do that all in one place
... or until we have right set of names
... is there an EPUB/Web IG and the rest of digital publishing
... there are a lot of important things to do
... Do we bulk up this charter for EPUB/Web
... or do we do as Deborah and I both read
... and it's about one specific item but acknowledge that there are many
other things to do
... Don't have a strong feeling, but likely the chairs would
Markus: First observation is that we have
severe resource constraints
... taking on everything that digital publishing could want makes me
cringe
... We should take a few steps at a time
... which steps are right for now is another question
... But an over-ambitious charter that does not reflect our
partiicpation ability today
Ralph: if we don't say we want to do those things, people may not come either
Tzviya: We want to keep this vision in mind
as we work on digital publishing
... having a separate WG
... we don't get other members other than those who are already here
... approach that Markus and I were taking is as a guiding principle
... maybe we need to take a closer look at what we can accomplish over
next few months
... and we could couch that in terms of EPUB/Web as the vision and less
of the deliverable
... I was going to add
Tzviya: Jeff mentioned the comparison to
what Web TV group did
... Dave is working in CSS, Tzviya and @ have been working in P&F
... spending time in the WG meetings
... yes, there is a resource limitation...recruit
... We do same thing
... ARIA draft we are working on should have a first public working
group soon
... it works
Charles: quick question
... with EPUB/Web naming; is it EPUB or Web or both?
Tzviya: We'll call it Houdini book
Deborah: Also about the naming issue
... when we talk about our focus as a group
... i wonder if I made a misjudgment
... I assumed that because it's called EPUB/Web it's being driven by
IDPF
... or by W3C?
Ivan: Markus and I have been writing down ideas
Deborah: To extent it will exist as a thing, will it be driven from W3C and the DigPub IG?
Ivan: I would like to be able to say that
neither in the sense that
... this is something that is driven by the two organizations in
cooperation
... how that is done admiistratively is a different issue
... i think the vision is something that came out of
... a joint discussion of two parties
... one from IDPF and one from W3C
... that is how I look at it
... it's owned by both and not exclusively owned by two
Deborah: that does imply more participation
from DPub and EPUB3
... which is a standard
Deborah: I'm trying to understand the level
of focus for EPUB /Web
... something to contribute to , or something that won't happen unless
we put energy into it
Ivan: part of that blue stuff has to be
removed; clarify understanding
... Difference of what is there today; publishing on web or on Bluefire
... these kinds of differences should disappear
... all the rest is additional stuff
... because we are bringingtogether two different worlds
... it's clear these two organizations are working together
... this is how the name came about
... i don't think either organization exclusively owns this
Markus: I don't know either
... the eventual nature of the WG that would take this into an
implementable reality is not...
... there is no ambition to start that WG
... but that list of building blocks that are necessary don't exist yet
... They would need to wait for the building blocks
... IG needs to do plumbing with other WGs within W3C to get something
implementable
Bill McCoy: EPUB/Web is a constellation of
specs to become more interoperable
... Say a couple words about it
... part of what you are asking is a branding and marketing question,
not a spec question
... whether it will be called EPUB or XYZ will depend upon the vector we
go on
... if EPUB1 succeeds on the building block specs
... there will be more desire to call it EPUB
... but if it takes a radical invention that takes it further from EPUB,
then we'll call it something else
... IDPF would prefer something that stays with EPUB and not undermine
our current work
... but we are happy to encompass the possibility that the branding and
technology will evolve
... not sure if that is any clearer
Nick: Two names to toss out there
... the packaged content group or published content group
... difference between a free blog and a $9.99 ebook is the package
... we have seen the package sell because it provides value
... things happen in the packaged content provides value
... it's an attempt to distill what's done in the print world
... and dertermine the value of packaged content in the spec
... it gets rid of the EPUB/Web
... and thinks about the value of the content
... packaged content and published content
Ralph: brainstorming for now
Ivan: only worry I have
... I understand what you say
... is not having any reference to the web may mislead
... I would modify it a bit by saying packaged web content
Nick: doesn't web mean online?
Bill: think Open Web Platform
Dave: sound too much like Apps
Ivan; A bit like WebApps
scribe: I understand what you say and the importance of packaging we discussed earlier today
Nick: something to think about
Paul: to the point about what organization
governs it or how the orgs work together
... a lot will depend upon how the existing specs exist or don't and how
they evolve
... EDUPUB specs combine together
... it's the alliance and an umbrella
... if we continue to leverage existing specs, we create new specs
... and who drives that
... it will get more complicated, but deal with it when we get there
Nick: lots of products out there
... when you brand it more broadly, you allow for more future things
... EPUB has done a great job for an online container
Paul: agree with that, but need something that is sexier sounding
Liisa: I want to go back to Deborah's
question
... Today the clear example we talked about today
... If we need to solve pagination, widows and orphans
... those things likely have a place in a WG within W3C
... we have worked at IDPF
... knowing they were unsolved problems and we did not address them
... We leaned on HTML and CSs
... and when they solve it they solve
... it. But now this group has the opportunity to raise the issue and
try to solve it
... it makes it better for the Web and for EPUB
Patrick: maybe one word of caution on
'what's in a name' thing
... I hope that people don't get spec fatigue if we name it something
else
... We have had EPUB2 that was pretty successful
... EPUB3 which was a lot of work
... but where is the traction in the authoring tools and consumer
understanding
... I understand the ideas here
... and the discussions with other WGs
... but at some point, I cannot keep up with what you were doing two
years ago
... maybe EPUB4.0
Ivan: We did have EPUB in our discussion in
the past
... fear we had is if we call it EPUB4
... the people working on EPUB3 will run away
Patrick: that is valid
Ivan: We called it EPUB Next
Patrick: that's how you will kill it
... maybe the lack of a name
Tzviya: Valdemordt
Dave: EPUB Zero
Markus: So what are next steps for the charter?
Ivan: This will go out as an advance notice
... saying this is a draft under discussions
... So we'll have some discussions this Friday
... and in coming weeks
... we will make changes
... it is on GitHub
<tzviya> http://w3c.github.io/dpub-charter/index.html
Ivan: so I would very much like if you
submit comments or pull requests
... to make our iife easier in the coming weeks
... When we feel it is mature enough
<tzviya> post issues to https://github.com/w3c/dpub-charter/issues
Ivan: Formally speaking we then give it to
W3C managment (w3M)
... and if they say yes, it goes out to W3C membership
... four weeks at the minimum
... but in summer we may give it six weeks
... Then we look at the responses
... there are always comments coming
... We take the comments into account
... If there are formal objections, then we have to deal with it
Ralph: The current charter ends Sept
... hope we want to continue meeting
... We want to have a new charter we are comfortable with by July 1
... so sharpen the pencils
Markus: Any more questions
Brady: Japan does fall outside of our
charter
... it is cutting plane reservations short
Tzviya: We are on the preliminary agenda
Ivan: If we can get charter done by end of
June
... then I do not expect W3M objecting to extend the current charter
until procedure ends
Jeff: for all the comments that Ivan made to
explain the process
... I am not aware of anyone who objects to this activity
... correct, we may have surprises, but unlikely to have objections from
a planning perspective
... sufficient apathy should be a guideline
... at least 5 percent of membership should join
... If everyone remembers to vote and wants to continue
... unless we put something surprising acidic in the charter
Markus: with 15 seconds to go...
... WebEx on Monday
... We thank you all for coming today
Tzviya: and thank Phil for hosting us today
[Applause]
scribe: and thank Nick for the peanut butter treat
[Meeting Adjourns]