Publishing Working Group Telco — Minutes

Date: 2018-02-05

See also the Agenda and the IRC Log

Attendees

Present: Baldur Bjarnason, Jasmine Mulliken, Teenya Franklin, Chris Maden, Avneesh Singh, Tzviya Siegman, Nick Ruffilo, Jeff Buehler, Peter Krautzberger, Evan Owens, Gregorio Pellegrino, Dave Cramer, Deborah Kaplan, Wolfgang Schindler, Tim Cole, Luc Audrain, Bill Kasdorf, Joshua Pyle, Ben Walters, Mustapha Lazrek, Ivan Herman, Evan Yamanishi, George Kerscher, Rachel Comerford, Garth Conboy, Hadrien Gardeur, Jun Gamou, Mateus Teixeira, Lillian Sullam, Ben Schroeter, Vladimir Levantovsky, Zheng Xu, Laurent Le Meur, Marisa DeMeglio, Ric Wright, Bill McCoy, Brady Duga, Benjamin Young

Regrets: Ivan Herman, Romain Deltour

Guests:

Chair: Tzviya Siegman

Scribe(s): Nick Ruffilo

Content:

• 1. Last week’s minutes
• 2. New members’ meeting
• 3. TAG comments
• 4. pending PR-s
• 5. Resolutions

1. Last week’s minutes

Tzviya Siegman: https://www.w3.org/publishing/groups/publ-wg/Meetings/Minutes/2018/2018-01-29-minutes

Tzviya Siegman: Minutes from last week - any comments? … Minutes approved

Resolution #1: last week’s minutes approved

2. New members’ meeting

Jasmine Mulliken: https://www.w3.org/2018/01/30-pwg-new-minutes.html

Tzviya Siegman: Next item - we had a meeting with new members last week. Minutes did go around but they are not in the agenda. If someone can paste them, great. Thank you to all who joined. The most important part of that meeting is that we seems to have - lost touch with reality. We go into technical detail in the call and on github but we have difficulty linking it back to use-cases and the specifications. Something at TPAC and was suggested last week is that when we talk about a technical detail is that we bring it back to a use-case. Ivan refreshed the use-case repository - which goes back to the DPUB group. Laurent had discussed working on this. Josh Pyle offered to work. When we talk about super-technical details, lets make sure that we take a step back and make sure there is a use-case about how it would work on the real world. Starting today, we’re going to keep a living document of use-cases.
… Lets make sure we work on this together, and we iron out logistics. The main point is that technical details are not the focus - but something usable is.

Ivan Herman: github repo for use cases: https://github.com/w3c/dpub-pwp-ucr

Hadrien Gardeur: One comment, we have been very abstract up to now - with an infoset. Working on affordances will be helpful as we will have to connect more directly to the use cases. It will get better in the next few weeks.

3. TAG comments

Garth Conboy: https://github.com/w3c/wpub/issues/32#issuecomment-362273649

Tzviya Siegman: Hopefully everyone had a chance to read this - or not. (issue #32)

Garth Conboy: The key is the question posed in the middle of the 2nd paragraph. Is it the goal of the group to make a new packaging format for reading, or to gain support for missing features and first-class support for items related to publishing. It may not be universal, but the argument there is that if we are in the second piece of the question - which matches with our charter - then there is a strong push to base off the web app manifest and proposing extensions - over rolling our own. If we roll our own, the likelihood of getting take-up in the browser community is much lower.

Ivan Herman: I think that’s the core of the problem. There are also references to the packaging spec and format. Because that is in a much earlier stage it’s a bit different and I don’t think it’s at the core of our discussions. In general - the relationship to browser acceptance and implementations is the core question. The answer to the question is - it’s not both. We are not in the business of defining a new packaging format. Our goal is to have something that works in a browser AND can be used in a packaged format in other environments. It’s not exclusive or questions.

Garth Conboy: PWP is the first of those two, and WP might be the second.

Hadrien Gardeur: I’m a bit conflicted. I’m hearing that we should be adopting the WAM and extending it, and on the other side, we’re getting notes that we shouldn’t expect browsers to handle offline, or other things we need. So it seems unfair that adapting WAM would get us any extra features or support. It was in another issues - and Baldur raised a bunch of questions that do not seem to be answered. If we use the WAM - there has to be some benefit, but if we don’t get implementation, why is it better to use the WAM instead of something else.

Jeff Buehler: Why do we care if the browser accepts the manifest? How does that affect the packaged web publication?

Tzviya Siegman: we need the browsers to recognize what we’re doing.

Garth Conboy: I don’t know whether - to what level of realism - one mode that we hear from some of the - there was the conference following TPAC - and you want to eventually have it so that a browser understands what a publication is - such as reading modes in some browsers. There is an argument that if you use the WAM - there’s an argument that if you’re using something that browsers are already using in some case - eventually browsers could understand web publications and paging between resources - which makes them native.

Jeff Buehler: So we want native support at a browser level - that runs the risk of limiting what the publisher may want to do. Do we have to design something that is adopted by browsers?

Garth Conboy: I’m not sure we’d take that as a fact, but it’s a potential perspective.

Ivan Herman: It’s more an answer to Hadrien - but it’s related. I think we have to realize that not everything is purely a technical issue. By giving the impression that we at least - try to reinvent lots of things - it will be more difficult to get things accepted by browsers -we have some browsers who can speak from their point of view. There is an element of social context here - to try to go as much as we can towards what is already there and implemented and do whatever is possible to rely on whatever is there.

Dave Cramer: We talk about something working in the browser - but there is a lot behind that phrase. EPUB works in the browser for some values on browser - such as edge. By itself, throw enough programming at something and you can make anything happen. So the question is how far do we want things to go, so is it having a publisher not need to write code?

Ben Walters: The points here and questions here are right. Publishers favor existing specs/techs. It’s not clear that WAM is close enough to be useful. I’ll agree with what the on-ramps for browsers are. Does it makes sense to package scripts? Do we make standardized extensions - do they align with WAM? I don’t have any answers, but I think we need to keep going along the lines of these questions - do we reuse WAM or something in the same vein.

Tzviya Siegman: https://www.w3.org/2017/04/publ-wg-charter/

Tzviya Siegman: we need to review the charter and make sure we all agree with it. Also - are we packaging what’s on the browser, or are we doing something differnet.

Tzviya Siegman: DPUB IG use cases https://www.w3.org/TR/pwp-ucr/

Teenya Franklin: are we talking about 4.3 Input Documents- Packaging on the web Section in the charter?

Benjamin Young: I would love for us to confirm some things - rather than operate on assumptions and dove right into spec’ing of assumptions. A lot of strain has been around the fact that we have different assumptions about what, who, and how it should happen. Clarifying those things - which the IG attempted with the use-cases. If we can map any specs we can write to map to those use cases, then we can make the case to browsers much easier. The TAG has their things they want us to use, and we have to have our reasons why we may not use them. WAM is incomplete for our needs, but we can go back and say why we need to iterate. We need to ask ‘why are we spec’ing and what’ - the who experience around having a publication.

Ivan Herman: Following what Benjamin said - it’s true that what we want is something that can be followed through with affordances, but we’ve also heard that all this can be done by clever javascript on the web - so what are we doing? The important point we’re doing is that it should be easy to create the environment that we are talking about. Even if it is doable by a clever javascript - we can and should try to standardize a kind of layer - that can be implemented once and for all, so others (in the general sense) could generate those publications very quickly and easily. That aspect of things - the fact that it’s realizable on top of the web platform today is not enough to say. That’s not the full answer. It should be realizable easily and quickly by laypeople - well relatively.

Benjamin Young: That’s fabulous and should be shared. Publishers have long-sightedness when looking backwards. Our publisher made books 200 years ago - for which the JS does not need to be updated. A sample that I created throws tons of features that are deprecated, and features that are not yet designed. You want to create something that things 200 years from now can read it. Javascript is not that. We need to declare if we want descriptive formats instead of prescriptive formats.

Gregorio Pellegrino: +1 descriptive

Jeff Buehler: Browsers will continue changing - constantly. In my experience, no matter what we design, the more specific we get, the more people will break out of specifications. I constantly have built epubs that break specifications because publishers need something that breaks the spec. People are going to do what they need. Not in terms of creating specifications, but hardwiring in notions of what a publication looks like. Whether in JS or what, but it’s important we keep flexibility. Lets not assume hard specs.

Tzviya Siegman: So we want things as simple as possible - but we might be conflating the web publication with the packaged web publication. I’d like my web publication to work in 30 years, but are we creating something new if we say it’s just HTML? What are we adding?

Ivan Herman: +1 to Hadrien

Hadrien Gardeur: We’re inventing the concept of a collection of resources - and saying something about it. On the web, we just know about resources, but not a collection. That’s pretty much all we’re doing. The rest is based on existing specs.

Ivan Herman: I agree with Hadrien - but it has some practical consequences - which Benjamin called ‘affordances’ which are based on that concept that Hadrien referred to - that we can continuously go through things - is all based on collection. Where we are adding something new, the only thing is what Hadrien said,, but it has practical consequences that we need to specify to make possible to use.

Peter Krautzberger: I wanted to counterpoint the arguments earlier - if you can still read a book from 100 years ago, you cannot read a book 100 years after Gutenberg - what you most likely have read is a reprint. I’m only saying this so that when we think about solutions, we shouldn’t think about the current state of the web, but what we expect to provide are solutions to a future.

Benjamin Young: The things we do with this collection - what do we stick in the format, etc. Knowing we need a collection of documents is insufficient. Beyond that is where the devil is in the details. It gets complicated when we need to go to a browser and ask for things, especially if we don’t really know. For example, the WAM. One thing it prevents is documents that lie outside of a scope URL, so you can’t make a publication from different URLs. Some have said it’s needed, some have said it’s not, but we don’t know if it’s an issue…

Benjamin Young: https://w3c.github.io/manifest/#navigation-scope – any link not “under” a URL, opens outside of the stripped-down browser

Joshua Pyle: I think we’ve fallen into the trap to talk about behavior rather than content. I don’t really care what a browser 100 years from now might do, but if we have good descriptive metadata, then leave it up to the browser. We have use cases, but if we build all these things into the standard - then we can defer all this behavior stuff. As far as javascript goes, i hope we don’t wind up with something that requires someone to include javascript ot make it work - then we really haven’t done our job?

Peter Krautzberger: anyone have a copy of their company website the way it looked this morning?

Deborah Kaplan: I’m an archivist - physical preservation are things that can be recovered. So much of digital preservation is ‘we will never get that back’ either media storage, dead links, file formats, etc. We shouldn’t say ‘this book isn’t readable because of javascript’ but we should make the definition of a readable book is that something is… In order to read this book you needs a R/G/B transparency… Come up with a set of rules that says: ‘this is readable and will continue to be readable in 10 years’ How many times have we worked on something fancy that were super-cool but broke because they required a version of flash that browsers simply stopped supporting… Write a simple, semantic spec that does not assume publishers are going to go crazy…

Wolfgang Schindler: +1 to dkaplan

Bill Kasdorf: what I’m hearing is that we should specify how to describe and structure a publication in a way that is agnostic as to how a given technology, now or in the future, would render it.

Jeff Buehler: +1 to agnostic, flexible, clear and simple spec

Ivan Herman: The problem I have is not technical - lets say we built a completely declarative standard - which defines the usage of HTML, CSS, and whatever. We do it in a way that it contains all the metadata - then we say ‘this is our standard’ - it would be great, but it’s also our job to ensure it can be and it is implemented. If it’s a standard that no browsers will implement because what we say is not implementable, then the whole thing is a nice intellectual exercise. That’s the tension we have. We are fine to do a pure content specification, but we have to make sure it’s implementable and implemented.

Peter Krautzberger: np

Tzviya Siegman: As Ivan said - I’d love to write a spec that had just the ideals… One idea that was tossed around - what do people think of the concept of a document that proposes basic HTML, CSS (externalized) and any interactivity be set as external, then we have a polyfill (however it’s implemented TBD) so someone writes it - so as a publisher - I put one line of script in my file, and call the polyfill, and yes, I include the script in every file, but if the User Agent ignores it, fine, but the book can function without the script in the User Agent has ability - but that means it can function with the script.

Garth Conboy: I say no because you go down the path of ‘where does the polyfill live’ and then ‘do publishers need to include that polyfill’ before this conversation, the question of there being NO requirements for any JS - and we’re closer to agreement on that. I do think the 1 line is taking happy pills, but it’s a slippery slope

Peter Krautzberger: I could see some path, and it could be modular enough - but pushing back against JS is weird as it’s something that is part of the web. At the same time, I find it difficult to image - from a resource list - as being adopted by the WAM - you just need a service worker - but why should a browser use your caching mechanism… But i can’t see a way without a polyfill…

Deborah Kaplan: I agree to what people say, You should be able to get content without JS. But, you should be able to add functionality. We don’t want to take functionality away, but I would counter that when it comes to things being basic - such as page turning - right now we’re defining a spec, but Tzviya, you have often heard my long rant about one thing we’ve done wrong is that we have allowed a ton of functionality that is common to nearly every page still remain as modular (such as menus, and all the javascript). but, we need to define the limited amount of functionality. As opposed to every publisher needs to write a polyfill and their own javascript. But I would want to be in the business to say that ‘these features are required’ And what would be a compliant reading system, that meets those minimums.

Laurent Le Meur: +1 to Deborah

Wolfgang Schindler: +1 to dkaplan

Jeff Buehler: +1 dkaplan - its the core functionality that seems to be the question

Ivan Herman: Wow, action items… On this whole issue about scripts added to a publication or not. I think realistically, we have two possibilities - either we produce ebooks on the web, and for those books to be properly consumed, we ask all the readers to include an extension/polyfill, OR for an intermediate period, the publishers add that type of polyfill - so the user has to do nothing. At least for a temporary period - this is the choice. Ideally I would like that nobody has to do that, but we have to be realistic

Laurent Le Meur: third way: between the publisher and the browser, open-source developers create the required polyfills.

Ric Wright: See also https://readium.firebaseapp.com/?

Bill Kasdorf: Epub is supposed to most use present technologies that works now. So we’re talking about one thing when we’re chartered to do 3.

Hadrien Gardeur: I don’t think we need a polyfill or the affordances on every single page of the publication. We’ve talked about the web publication address for a user-agent that doesn’t know about things. So the only page that needs the affordances is that page. We don’t need to polyfill the resource of that publication, but the only thing that needs the polyfill for that specific address. In the concept of readium, that’s the case. If you have a different link that works in browser, that’s great.

Tzviya Siegman: you might not even need it in the content.

Bill Kasdorf: WP should be the most technology agnostic, adaptable to future developments, EPUB should be the most practical using presently available Web technologies, PWP should be somewhere in the middle.

Ivan Herman: I don’t think - Hadrien - that anyone said the polyfill would need to be present in all files. It can be referred to in the manifest, but only in one place.

Jeff Buehler: +1 polyfill should not be required to be part of a publication

Tzviya Siegman: In these last few minutes, garth is anxious to take this boat… Do we agree that a polyfill or a script (for rendering of a publication) should not be part of the publication

Deborah Kaplan: +1

Bill Kasdorf: Should not be in WP, but could be in EPUB 4

Joshua Pyle: +1

Zheng Xu: +1 not required to be part of publication

Nick Ruffilo: +1 - no polyfill should be required to be included in a publication for the publication to be read

David Stroup: +1 - not required

Luc Audrain: +1 to Nick

Wolfgang Schindler: +1 to Nick

Baldur Bjarnason: +0 I have no idea. Too early to tell. Depends a lot on what pathways browser vendors are interested in taking for publication support.

Brady Duga: +0, echo baldurbjarnason

4. pending PR-s

Tzviya Siegman: https://github.com/w3c/wpub/pull/130

Ivan Herman: the first question is whether it is good enough to be merged into the main document - if it’s a good direction for the pull request to be merged. Maybe we can agree by the end of the week via email. There is a much smaller pull request on internationalization.

5. Resolutions

• Resolution #1: last week’s minutes approved