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