Publishing Working Group Telco — Minutes
Date: 2018-07-23
See also the Agenda and the IRC Log
Attendees
Present: Avneesh Singh, Deborah Kaplan, Dave Cramer, Ivan Herman, George Kerscher, Jeff Buehler, Tzviya Siegman, Wolfgang Schindler, Juan Corona, Wendy Reid, Luc Audrain, Jun Gamou, Hadrien Gardeur, Chris Maden, Murata Makoto, Joshua Pyle, Gregorio Pellegrino, Ben Walters, Franco Alvarado, Laurent Le Meur, caitlingebhard, Brady Duga, Ric Wright, Lillian Sullam, Reinaldo Ferraz, Derek Jackson, Marisa DeMeglio, Harriett Green, Charles LaPierre, Mustapha Lazrek
Regrets: Vladimir Levantovsky, Benjamin Young, Rachel Comerford, Romain Deltour, Bill Kasdorf, Jasmine Mulliken, Teenya Franklin, Tim Cole, Matt Garrish, Garth Conboy
Guests:
Chair: Tzviya Siegman
Scribe(s): Dave Cramer
Content:
Tzviya Siegman: let’s get started
… welcome back from our far-too-short break
… any comments on the minutes?
Tzviya Siegman: https://www.w3.org/publishing/groups/publ-wg/Meetings/Minutes/2018/2018-07-09-pwg.html
Tzviya Siegman: minutes approved
Resolution #1: meeting of two weeks ago approved
1. publishing new draft
Tzviya Siegman: we have a few open issues
1.1. cover
Tzviya Siegman: https://github.com/w3c/wpub/issues/261
tzvoya: this is cover vs cover-image
… look at last comment from Matt
… we’re concerned about the infoset
… Matt says we should be concerned with language
… so we’re just discussing changing language
… should we say cover or cover image or cover page
Deborah Kaplan: the one thing that has happened in github
… the people who wanted a discrete cover page
… I think the people in github would be fine with cover image
… when I gave the whole “here are some guidelines” thing
… I think people bring up stuff that doesn’t need to be in the infoset
… it’s fine to document these extra things
… so we should go back to the github issue later
… I think my comment addressed everything except for the infoset Q about a cover that is not a cover image
Tzviya Siegman: perhaps we can open a new issue
… the proposal that you had, can you sum it up?
Deborah Kaplan: my proposal for infoset purposes
… I was going based on the assumption that because
… Ivan reminded us that at the F2F there needed to be the idea of a cover, that might not be image
… I don’t think we need both cover and cover-image
… but if people feel strongly about a cover that is not an image that still needs to be in the infoset
… the reason people want cover images in infoset is for shelf view, etc
… that reasoning doesn’t apply to a cover
… will anyone go to bat for needing a non-image cover IN THE INFOSET
Joshua Pyle: I would make a strong case for a cover that’s not an image because not all content includes imagery
… just point to something, and if it’s an image then great, if not they could render the html
… for scholarly articles, the cover would be title/author/ journal / issue
Deborah Kaplan: Josh: see https://github.com/w3c/wpub/issues/261#issuecomment-406696836
Deborah Kaplan: This comment specs out all of that.
Tzviya Siegman: that’s already been mentioned in an issue
Joshua Pyle: but there are 70 comments
… I don’t think we should have both a cover and cover image
Laurent Le Meur: we should close issue by saying we define cover-image
… discuss elsewhere if we need another type of cover
… user agents could assemble image from metadata, wouldn’t need html
Tzviya Siegman: josh proposed just cover
… the publisher can include image OR text in html
… the user agent would do some magic to display
Laurent Le Meur: I think the magic to display HTML is more than magic to assemble from metadata
Deborah Kaplan: I put a link to my github comment
… for later, when we are writing recs for what UAs should do
… we will need to have guidelines for what to do when you don’t have a cover
… I’m happy with not having both
… the diff between Laurent and Josh
… in the absence of an image, do we recommend the UA wants to extract metadata and make cover?
… or do we think UAs should tried to define a text cover somehow
… I would go with Laurent
… it’s a standard practice now that you get title/creator in shelf view if there’s no cover
… if your business case is that it’s important to have specific information on the cover, then you should probably actually create an image
Wendy Reid: from experience with Kobo, that’s what we do
… if we have image we use it
… if there’s no image file, then we create cover with metadata
… that’s very standard
Ivan Herman: I don’t understand the controversy
… I thought Josh’s proposal was fine
… there’s a cover, if you put image there you get image, if HTML is there you render that
… and in the scholarly world, title and author might not be enough
… you need standard metadata
… I don’t understand the problem
Joshua Pyle: +1 to Ivan expressing my business case better than I did.
Tzviya Siegman: a reminder that we’re only talking about the infoset
Laurent Le Meur: if we follow josh, it means every UA will have to be able to take an arbitrary HTML file or something else and try to make a cover out of it
… this puts a burden on user agents
Joshua Pyle: I think that UAs should do what they think is best
… using this approach, you have something called a cover that points to image or file
… if UA doesn’t know how to turn html into shelf-view icon, it can still use metadata
… we should provide as much guidance as possible to UA, then let UA choose
Tzviya Siegman: we might need to decide to publish without this
George Kerscher: just an image is too limiting in terms of looking at the future
… I see discussions about VR and innovation in the book space
Tzviya Siegman: straw-poll: [1] include cover which could be anything or [2] just a cover image ?
Laurent Le Meur: 2
Deborah Kaplan: 2
Juan Corona: 1
Hadrien Gardeur: 2
Ivan Herman: 1
Tzviya Siegman: 1
caitlingebhard: 1
Joshua Pyle: 1
Wendy Reid: 1
Derek Jackson: 1
Wolfgang Schindler: 1
Franco Alvarado: 1
Ric Wright: 2
Gregorio Pellegrino: 2
Luc Audrain: 2
George Kerscher: 1 cover
Lillian Sullam: 1
Charles LaPierre: 1
Marisa DeMeglio: 1
Jeff Buehler: 1
Mustapha Lazrek: 1
Ric Wright: 1
Tzviya Siegman: I see more 1s than 2s
Ric Wright: I inadvertently entered a 2.
Ivan Herman: I would propose to put there the more permissive approach 1, publish a draft (which isn’t final)
… and see what the community has to say
… we don’t have unanimity
… this is just a draft
… easier to restrict early
1.2. language and direction
Ivan Herman: https://github.com/w3c/wpub/issues/220
Ivan Herman: we had question of direction ltr rtl
… trouble expressing in JSON
… consensus in discussion that rtl/ltr we don’t have other means than fallback on unicode directional markers
… and no explicit default direction setting
… i think laurentlemeur we have agreement
Laurent Le Meur: yes
Ivan Herman: a more general issue came up
… related to the language setting
… there are 2 different things
… 1. if I set language in manifest in one of schema.org terms inLanguage
… this means I set language for publication at large + text of manifest
… individual resources may not set their own languages, there may be discrepancies
… 2. the other approach is more complicated
… when the manifest is embedded in html
… looking at that case it would be logical that the script element with manifest inherits language and dir of entry page
… so if it’s part of html then I could and maybe should refer to what HTML does
… we still say that if you do it that way you’re talking about the publication as a whole
… when we have an embedded manifest, do we inherit the HTML settings?
… or not?
… an additional argument… there is one thing from HTML structure that we will inherit: the base URL
Tzviya Siegman: I put myself on the queue
… the schema.org group is aware they have language issues, but they’re trying to work it out
… they know language on particular tags is a problem
Ivan Herman: yes, the setting of a language for an individual text is already there
… we hope schema.org handles it eventually
… the json-ld working group, partly on my instigation, is looking at issues of embedded json-ld
… it was non-normative in 1.0
… for example, there’s no resolution on inheriting baseURL
… I think that will be resolved in 1.1
Laurent Le Meur: in fact, here we are trying to do 2 things
… the language of publication is descriptive metadata
… if we want to infer the language of manifest, that’s simple
… we can do that in json-ld with @language in context
… so we are trying to simplify work of authors
… by inferring from publication language
… and maybe we should inherit from html if manifest is embedded
… but that makes processing of detached and embedded manifests different
… this is why we should infer language from publication language
Tzviya Siegman: what q are we answering?
Ivan Herman: the current text needs to be rewritten
… at least for embedded version there are two ways of rewriting
… if you want detachable things then use @language
… we have two difficulties, i agree with this one
… if we ignore surrounding html we will end up defining something which is not aligned with how json-ld is used in html
… I don’t know which one is a bigger danger
Tzviya Siegman: the Q is, whether we use something we are sure will work detached or embedded, but might overwrite default/be in conflict with processors
Ivan Herman: I dont think this is correct
… . if you use @language it works everywhere
… if I don’t put anything in JSON_LD or any other thing, what happens then?
… in one case a language might be inherited, in the other case not
Ivan Herman: @language is so far away from the standard syntax for authors; extending a context is very difficult to follow
Laurent Le Meur: the context line in json-manifest should be copy/paste; should not be edited
… it’s not about metadata, not about structure
Tzviya Siegman: can we come to consensus?
Ivan Herman: we should do a PR knowing there are issues, and we don’t know
… I can try to write up the more complex situation and see where it goes
Laurent Le Meur: let’s try to write it
Ivan Herman: I will come up with a PR, hopefully this week
2. implementations
Tzviya Siegman: we can publish a new draft, and thus more work
… the goal of the draft; we would like to see implementations
… we have lots of implementers in this group
… we will ask you to commit to this now
… what we really want is a lot of issues. tell me the problems!
… Josh is going to do this.
… anyone else, please try this
Ivan Herman: we should make it more precise
… describe more details
… right now we have only vague ideas about affordances
… this is the missing thing
… we have lots of metadata in the manifest
… we want an implementation which does minimally two things
… 1. navigate through resources
… 2. and do something—offlining, caching, whatever—I want to read on the plane
… these are the two challenges
Tzviya Siegman: you can take your time
… take a month, if you need more that’s good
George Kerscher: do we only want browser/RS systems or authoring tools?
Ivan Herman: only reading, we should’t worry about authoring yet
Hadrien Gardeur: I created an issue about processing manifest into webidl
… this is relevant here
… what I listed is what any implementation will have to do
… it can be a big challenge to go from the many different things allowed to an in-memory model for basic implementation
… it’s non-trivial to convert this manuscript into webidl
Tzviya Siegman: see https://github.com/w3c/wpub/issues/268
Tzviya Siegman: we are ok with partial implementation
… and we do want to hear about problems
Hadrien Gardeur: I’m not saying there are problems, there is just lots of work
Ivan Herman: I agree
… we have to be careful that what is currently in the doc around IDL is out of date
… we shouldn’t spend time redoing that before next publication
… I am looking at an implementation on that
… to do it in Node
… for implementors: json-ld has a bunch of APIs which convert json-ld into different types of json-ld
… and so can you can create something simpler using existing tools
Tzviya Siegman: we do intend epub4 to be a packaged version of WP
… so this will give you a head start on epub4 work
Hadrien Gardeur: for a partial and specialized implementation, what I’ve done for audio is already such an implementation
Wendy Reid: I don’t want to speak for kobo but I’ll talk to Jeff
Avneesh Singh: this is only the 2nd public draft
… have to start on accessibility review
… when is right time to start?
Ivan Herman: my plan was that once this draft is out, I will start bugging r12a for i18n review
… harder to do these reviews when things are close to final
3. use cases
Tzviya Siegman: josh did an overhaul
Tzviya Siegman: https://w3c.github.io/dpub-pwp-ucr/
Joshua Pyle: I hope everyone had a chance to loook
… there’s not a lot of new writing, but lots of reorganizing
… so I want to write the layout hints
… and would like to write use cases for cover images
… the ultimate goal is to create good solid anchors to the UCR that we can add to the spec
Tzviya Siegman: that’s good
Joshua Pyle: I know there are missing UCRs
… if you know of non-documented use cases please open an issue
… we want to republish soonish
Tzviya Siegman: thanks Josh
… looks like we won’t get to the other agenda items
… prices for TPAC go up at end of month
… any other business?
… and that’s it!
4. Resolutions
- Resolution #1: meeting of two weeks ago approved