DPUB IG F2F, New York, USA

Packaging for the Web

<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

Nick: I work for AerBook ... a start-up that allows anyone to create a store

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

Identifiers

<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].

Pagination, Styling

<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

Accessibility

<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

Education & Outreach

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].

Rechartering

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]