Publishing Working Group Telco — Minutes

Date: 2017-08-28

See also the Agenda and the IRC Log

Attendees

Present: Ivan Herman, Tzviya Siegman, Deborah Kaplan, Jeff Printy, Jun Gamou, Baldur Bjarnason, Benjamin Young, Rachel Comerford, Avneesh Singh, Ben Dugas, Matt Garrish, Lillian Sullam, Leonard Rosenthol, Dave Cramer, Ben Schroeter, Romain Deltour, Peter Krautzberger, Tim Cole, Bill Kasdorf, Heather Flanagan, George Kerscher, Marisa DeMeglio, Harriett Green, Hadrien Gardeur, Charles LaPierre, Laurent Le Meur, Ric Wright

Regrets: Vladimir Levantovsky, Luc Audrain, Mateus Teixeira, Garth Conboy

Guests:

Chair: Tzviya Siegman

Scribe(s): Rachel Comerford, Charles LaPierre

Content:

Leonard Rosenthol: mazel tov to @rdeltour

Ric Wright: Where is the traditional photo?

Romain Deltour: .me both the kid and the mother are sleeping in :-)

Ric Wright: Good plan

1. Welcome new members

Lillian Sullam: Penguin Random House working on the ebooks team

2. Minutes of last week

Tzviya Siegman: https://www.w3.org/publishing/groups/publ-wg/Meetings/Minutes/2017/2017-08-21-minutes

Resolution #1: meeting minutes approved

3. Open issues

Tzviya Siegman: Minutes approved
… we’re going to review a bunch of pull requests and look at open issues

Tzviya Siegman: https://github.com/w3c/wpub/pulls

Tzviya Siegman: there is one open pull request

Tzviya Siegman: There has been substantial time to discuss this request
… there are no open pull requests at this time
… if you would like to edit please open a pull request
… first open working draft by TPAC

Tzviya Siegman: We have a list of open issues to discuss today

Tzviya Siegman: https://github.com/w3c/wpub/issues/4

Tzviya Siegman: issue 4: who’s responsible for publication users interface
… I would recommend closing this issue now

Deborah Kaplan: +1

Leondardr: this is a concise issue that affords discussion; if wepull this into affordances then it will be lost

Benjamin Young: we do still need an answer for #4…

Tzviya Siegman: this has been open for a while but not commented on - no one has picked it up but we will need to discuss it with affordances
… there’s room for comment in how it aligns to affordances

Dave Cramer: this is large and complex, we need to keep that in mind when addressing. I’m siding with keeping it open or closing it.

Benjamin Young: I would leave number 4 open for reasons I will outline in IRC because Rachel lost the thread. We need to talk about scoping

Ivan Herman: the reason I brought this up is true for other issues - we tend to go into hugely complex semantic arguments.
… we try to resolve many issues under one

Benjamin Young: I would be happy to close issue 4 and narrow the scope against the affordances issue. This will inform the spec that delivers the affordances and let it come back up with other issues

Tzviya Siegman: the goal of closing is not to ignore - it’s to update the document and narrow the focus to resolvable issues

Leonard Rosenthol: we all agree this is not resolved and needs more discussion for closing - why not leave it open til we are at a place to address it for actually close it

Ivan Herman: but there are loads of comments that stray from the original issue

leondardr: I’m asking about process - do we close this broad topic and open lots of little ones

Benjamin Young: there are a lot of important topics in this. “responsible” is unclear from who is rendering to what is rendering
… visual vs auditory, not contextualized, etc
… I would love to narrow it down

Tzviya Siegman: I propose bigbluehat and dauwhe open sub issues and close this
… larger issue

Tzviya Siegman: https://github.com/w3c/wpub/issues/11

Ivan Herman: we have to control the long term and get in the habit of closing issues that are resolved. The goal is to close issues as soon as possible - when it’s in the doc with minimum concensus

Tzviya Siegman: Issue 11
… TimCole is this all addressed at this point - we settled on URL as identifier

Ivan Herman: I prefer to put a comment in the list that this issue is closed, when, and what minutes to review
… Tzviya is noting to do that

Tzviya Siegman: Issue 12

Tzviya Siegman: https://github.com/w3c/wpub/issues/12

Tzviya Siegman: I’m not sure where we’re headed on this one

Ivan Herman: for the records, agreement to close 11, 12

Matt Garrish: it kind of ties into affordances
… it can be closed off

Tzviya Siegman: Issue 14

Tzviya Siegman: https://github.com/w3c/wpub/issues/14

Tzviya Siegman: proposal for accomplishing pagination in navigation

Dave Cramer: not really pagination

Ivan Herman: Next and previous in browser is ignored

Benjamin Young: also…since this is a new spec, browsers might learn some new tricks, right? :)

Dave Cramer: I want something that acknowledge when you are in a primary resource what is the next primary resource.

Tzviya Siegman: can we close this issue because it’s a nonstarter

Dave Cramer: if the consensus is that this is irrelevant we can close

Tzviya Siegman: issue closed
… Issue 15

Tzviya Siegman: https://github.com/w3c/wpub/issues/15

Laurent Le Meur: +1 to close 15

Tzviya Siegman: closing this issue - all in agreement

Tzviya Siegman: https://github.com/w3c/wpub/issues/18

Ivan Herman: close 14, 15

Tzviya Siegman: Issue 18

Tzviya Siegman: https://github.com/w3c/wpub/issues/44

Tzviya Siegman: another issue about identifiers - the opinion that Ivan expressed is this is superseded by 44

Ivan Herman: this one is less precise that issue 44

Tim Cole: Ivan has characterized correctly - there didn’t seem much support
… I can add more information to 44 - we need to discuss alternative ways of doing this

Ivan Herman: for the records close issue 18

Tzviya Siegman: we can add this to the agenda
… Issue 24
… requirements of a titles

Tzviya Siegman: https://github.com/w3c/wpub/issues/24

Tzviya Siegman: this has been resolved by the current version
… agreed - closing 24

Ivan Herman: for the records: close 24

Tzviya Siegman: Issue 30 and 20
… duplicate one another. These are both resolved.

Rachel Comerford: For the records: closing 30 and 20

Tzviya Siegman: Issue 35

Tzviya Siegman: https://github.com/w3c/wpub/issues/35

Tzviya Siegman: to an extent this has been incorporated as a fallback in the current proposal due to expanded use of tags in HTML and other preferred uses of serialization
… recommendation to close this for now and come back to it in the future if we need to
… dauwhe? bigbluehat?

Dave Cramer: requesting more time for review and clarification

Benjamin Young: +1 to more time…

Tzviya Siegman: issue 36
… overlaps with issue 26, can we close one?

Ivan Herman: actually, both of them (36 and 26) have been taken over by the most recent document
… in that sense we can close both and the document may result in new issues being raised
… closing 26 and 36

Ivan Herman: Issue 42

Ivan Herman: this should be kept open
… it’s not clear what we’re saying re: language

Matt Garrish: I will add most recent discussion

Tzviya Siegman: When closing an issue - point to the pull request in closing comment
… should one be closed (29) in favor of 42?

4. manifest serialization

Tzviya Siegman: JSON or Not

Tzviya Siegman: https://github.com/w3c/wpub/issues/7#issuecomment-323436810

Tzviya Siegman: welcome everyones’ feedback.

Ivan Herman: 1 point of clarification…

Ivan Herman: This is making it clear once and for all that we are using JSON for manifest

Dave Cramer: I have commented out many things in html or xhtml file for troubleshooting, content to temporarily remove, explanatory notes
… JSON is a format with comments and so we use a certain flexibility

Baldur Bjarnason: I want to note that one issue with html is that it is as complicated as xhtml in terms of cognitive load, teaching etc
… as a response to dauwhe, part of the the reason we need comments is the complexity
… JSON is not more complicated than html but in this case it is better than html

Ivan Herman: commenting something out in JSON is something I want to do all the time and that problem is real
… the problem is this boat has sailed - it’s a standard now
… it the language that we use in this community and if we want our results to be accepted, it is what we must use.

Dave Cramer: this is not proposed html as an alternative but if we go on a JSON like path, YAML (sp?) allows for commenting

Benjamin Young: 2 pieces - I’m not sure who we’re providing a manifest for
… browsers don’t use JSON

Baldur Bjarnason: YAML is a pretty extensive object serialisation format whose extensive capabilities have caused security problems in the past and doesn’t work particularly well in a browser context. And inventing our own format is super risky

Benjamin Young: (restating for scribe)

George Kerscher: in a publishers workflow, xml would maintain content and then moves it off to JSON without comments but then the original element would maintain the publishers intended content

Benjamin Young: who are we providing the manifest for? JSON is great for developers who will use it to make HTML-based UX for an in-browser reading system

Benjamin Young: related to Web App Manifest, browser do not use JSON, “installers” do

Benjamin Young: Web App Manifest is used to create icons on a desktops and other launchers to load a browser

Benjamin Young: it does not “manifest” anything. it does not state resources. it references some icons and a start URL.

Benjamin Young: the Web App lives separately

Laurent Le Meur: the production workflow won’t change - they will continue to produce multiple formats

Proposed resolution: we should go for JSON (Ivan Herman)

Deborah Kaplan: +1

Laurent Le Meur: +1 for JSON

Charles LaPierre: +1 JSON

Ivan Herman: +1

Hadrien Gardeur: +1

Baldur Bjarnason: +1

Tim Cole: 0

Peter Krautzberger: +1

Ric Wright: +1

Romain Deltour: +1

Leonard Rosenthol: +1

Jun Gamou: +1

Benjamin Young: -0

Bill Kasdorf: 0

Matt Garrish: +1

Rachel Comerford: +1

Marisa DeMeglio: +1

Ben: 0

Harriett Green: +1

George Kerscher: +1 to a single way, json

Resolution #2: we should go for JSON

Ivan Herman: I think this closes issue 7

Tzviya Siegman: agreed

5. metadata proposal

Tzviya Siegman: https://docs.google.com/document/d/1ONzPOG-QwLwWeYpf_cPsvfc6cLGDRmHAEnql967dvEU/edit?usp=sharing

Tim Cole: there are properties that make this relatable and findable in a body of content
… publisher vs creator, publication date…
… the manifest may have a title that differs from what goes to the library

Laurent Le Meur: all information inside the manifest is defined as metadata
… everything in there is a subset of the information in the content. Manifest is metadata and metadata container

Leonard Rosenthol: there is a difference in opinion on what the metadata represents and what we are doing with it
… is it for the user agent in order to consume?
… is it meant for external processors?

Laurent Le Meur: the manifest represents metadata relative to the publication. title, authors, dates are metadata, clearly. The reading order can also be considered publication metadata.

Ivan Herman: I think leondardr said 99% of what I wanted to communicate - but also, the data in the manifest meant for the user agent can also be used for external processors
… what is used from dublincore and schema.org etc is meant for libraries, reading systems

Charles LaPierre: this is important for discoverability and accessibility (in alignment with schema.org)

Tzviya Siegman: there are a lot of comments on this document
… can we get a cleaned up version

6. Web App Manifest relations (starting…)

Leonard Rosenthol: +1

Tzviya Siegman: we have not committed to this but are starting exploration

Ivan Herman: to make things clear, we are not working in isolation. If we decide this is not for us and we need to have well documented reasons
… that are well formulated with clear exampled
… a separate task force makes sense
… there has been some discussion on the relevant issue
… if we ignore this it will backfire in terms of browser manufacturers that already use it

Laurent Le Meur: I’m interested

Tzviya Siegman: Volunteers

Rachel Comerford: rdeltour, larentlemeur, bigbluehat…

Ivan Herman: one more thing - once we have a consensus about 1 or 2, we can discuss
… we should get time at TPAC if we can
… we should go to TPAC with some choices

7. Misc

Tzviya Siegman: REGISTER FOR TPAC (please and thank you)
… no meeting next week for US Labor DAY

8. Resolutions