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:
- 1. Welcome new members
- 2. Minutes of last week
- 3. Open issues
- 4. manifest serialization
- 5. metadata proposal
- 6. Web App Manifest relations (starting…)
- 7. Misc
- 8. Resolutions
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
- Resolution #1: meeting minutes approved
- Resolution #2: we should go for JSON