Publishing Working Group Telco — Minutes

Date: 2017-08-14

See also the Agenda and the IRC Log

Attendees

Present: Leonard Rosenthol, Ivan Herman, Tzviya Siegman, George Kerscher, Ben Dugas, Laurent Le Meur, Baldur Bjarnason, Avneesh Singh, Jun Gamou, Benjamin Young, Bill Kasdorf, Bill McCoy, Rachel Comerford, Deborah Kaplan, Romain Deltour, Evan Yamanishi, Yuri Khramov, Mateus Teixeira, Marisa DeMeglio, Katie Haritos-Shea, Ric Wright, Garth Conboy, Ben Schroeter, Reinaldo Ferraz, Peter Krautzberger, Chris Maden, Hadrien Gardeur, Tim Cole, Brady Duga, David Stroup

Regrets: Vladimir Levantovsky, Matt Garrish, Luc Audrain, Charles LaPierre

Guests:

Chair: Tzviya Siegman

Scribe(s): Leonard Rosenthol, Dave Cramer

Content:

Tzviya Siegman: getting ready to start…
… most likely a packed meeting

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

Tzviya Siegman: first order of business - minutes…
… comments?
… minutes approved!

Resolution #1: Last week’s meeting minutes approved

Tzviya Siegman: introductions? Who’s new?

Garth Conboy: <lurking from a plane, you all work hard! :-)>

BenShroeter: a11y manager at Pearson

Leonard Rosenthol: (hard to hear - very echoy - other Ben, who hasn’t identified himself)

Bill Kasdorf: Ben Dugas from Kobo

Leonard Rosenthol: what’s his handle?

Katie Haritos-Shea: been with WCAG since 2001. excited with DPUB work. will be involved as can
… large involvement in a11y

Leonard Rosenthol: and Katie too please, Rachel

George Kerscher: welcome Katie

1. Manifest synthesis, scope, outstanding issues

Tzviya Siegman: what is a manifest? let’s talk some more about this…

Tzviya Siegman: https://rawgit.com/w3c/wpub/manifest-consensus-proposal/index-manifest-proposal.html#abstract-versus-concrete-manifest

Tzviya Siegman: there is a link about the abstract vs. concrete issues
… first we decide what we need (but not how it looks)
… and then we can figure out what it looks like and how they works
… but we started on MUST and SHOULD (and then to fallbacks, explicit, et.)

Romain Deltour: asking, are these concepts (abstract/concrete) that will appear in the document or just for helping us figure it out?

Tzviya Siegman: could go either way…but we do need to understand is needed
… the what then the how

Ivan Herman: I find it helpful to have that info in there in the doc, as it will hopefully also have info about fallbacks and such that would be relevant in the doc
… the concepts (but maybe not terms) are helpful
… it will also help people who are new to the grup (and the area)
… but maybe we will remove it in the future, but is good for now
… but my original reason for being on the queue was…
… to explain what we tried to do with the document and trying to come to consensus
… and where we knew there were issue (like secondary resources) made those should’s
… also listed outstanding issues so we have them tracked
… for FPWD, this is a good thing that people se where we are
… and with respec, it could easily go into the main doc

Bill Kasdorf: default reading order in abstract as a must. Consensus?
… I am not longer convinced it should be a must, but won’t argue
… item #7, its a must

George Kerscher: default reading order is an interesting creature, as some documents don’t necessary have one
… but there always needs to be a well defined entry point
… so let’s embrace the concept that documents are designed to be consumed differently

Bill Kasdorf: let me clarify, things like newspapers, magazines, etc. don’t need a default reading order
… but George’s suggestion is also good too, about navigating to other primary resources
… identification + navigation

Deborah Kaplan: there needs to be an order for the reader - where there is an algorithm
… that a tool can use to “scrape the text” and be sure that every page is hit

Chris Maden: Traversal requires a set, not a list.

Deborah Kaplan: is there an order where every resource can be reached?

Benjamin Young: recently worked on a magazine and there were huge discussions about the “reading order”, there was an order/sequence for the user

Rachel Comerford: +1 bigbluehat

Leonard Rosenthol: we’re mixing two concepts: identifying the default order
… that’s what
… ‘s suggested but not the only one
… and there’s what Deborah brought up, which is navigation or traversal
… those are different concepts

Leonard Rosenthol: let’s not complicate default reading order (of which there can be many others) with traversal

Bill McCoy: I wanted to say: IMO we should avoid being so general as to make every web page (even every static web page) to automatically be a “publication”… this is not the Web Platform WG

Bill Kasdorf: also agrees with @bigbluehat

Benjamin Young: +1 to the importance of “default” in “default reading order”

Bill McCoy: thus I agree with dkaplan3 that a order of the content is one distinguishing characteristic of a publication/document vs. arbitrary web page / web site

Ivan Herman: an abstract manifest should have an identifier - we missed that :(.

Ivan Herman: do we want to try to cross all the ‘t’s today and move this into the doc?

Katie Haritos-Shea: default is just one, not the only. and let’s not mix up navigation with default reading order

Avneesh Singh: i like this document, esp. the open issues
… going through the comments, from a11y, navigation is a stronger requirement than default reading order
… so, we may have a statement that default reading order can be optional if proper navigation is provided for all primary resources.

Tzviya Siegman: perhaps we need a best practices for some of these things?

Deborah Kaplan: +1

Tzviya Siegman: building on @ivan, how do we feel about using this as a starting point?

Tzviya Siegman: +1

Bill Kasdorf: +1 to FPWD

Ivan Herman: +1

Jun Gamou: +1

Benjamin Young: +1

Bill McCoy: +1

Leonard Rosenthol: +1

Tim Cole: +1

Katie Haritos-Shea: +1

Laurent Le Meur: +1

Rachel Comerford: +1

George Kerscher: +1

Ben Schroeter: +1

Ben Dugas: +1

Evan Yamanishi: +1

Peter Krautzberger: +1

Romain Deltour: 0

Ric Wright: +1

Baldur Bjarnason: 0

Avneesh Singh: +1

Tzviya Siegman: any comments on the zeros?

Dave Cramer: just to clarify on FPWD vs. Editors draft? we’re not close to FPWD

Ivan Herman: FPWD by end of year and the ED leads to that

Dave Cramer: that’s fine just worried about us ending up in corner

Ivan Herman: everything will evolve, and also beyond the FPWD
… as long as things are spread all over the place it’s hard for the editor. Moving stuff into the main doc should help things.

Romain Deltour: my 0 is really about the abstract manifest and information set and I would like to see that in the FPWD
… otherwise things are confusing from the draft and the terms may make it into normative text (and then are harder to get out)

Tzviya Siegman: so only speak on concrete?

Romain Deltour: yes

Ivan Herman: what I would propose, related to manifest, is to see how abstract moves to concrete
… big elephant is serialization and embedded
… I will write up something about defining the concrete and we can work through that
… but in the meantime, let’s leave it as is
… undecided but have a bias

Resolution #2: the document can be used to go into the Editor’s draft, modulo minor editorial changes as discussed at the meeting

Tzviya Siegman: let’s not use the term abstract, it’s confusing
… and that means lots of work for Matt
… so let’s start on some concrete items
… URLs, IRIs, etc., a big topic. Do you want to pick it up now?

2. URL, URI, IRI

Tim Cole: I submitted a pull request about this

Ivan Herman: so maybe we should hold off on this?
… trying to find the issue #

Tzviya Siegman: https://github.com/w3c/publ-wg/issues/21

Ivan Herman: most of us would agree that for spec purity we should use IRI
… but in practice the web dev community no longer use the term IRI and instead everything is a URL
… so if we use IRI, those people won;t know what we are talking about (and how it relates to the web, which doesn’t use that term)

Tim Cole: https://www.w3.org/TR/html5/references.html#refsURL

Ivan Herman: if you look at HTML 5.x spec, there is a strange approach to URL with a reference and a note about using the term URL (but it’s not necessary what is written in the RFCs)
… and while this is completely crazy, it’s what we’re stuck with

Romain Deltour: the newer URL ref, which points to the whatwg:

Romain Deltour: https://www.w3.org/TR/html/references.html#biblio-url

Katie Haritos-Shea: +1 to URL per HTML 5

Ivan Herman: so we should reference URL in HTML 5.x and just follow their lead (even if we don’t agree with them)

Laurent Le Meur: +1 to Ivan

Garth Conboy: +1 (URL)

Tim Cole: I am sympathetic to that, but I have concerns
… syntactically (URI and IRI) they are defined by the same spec
… but they aren’t the same in term of the way things are used (links vs. namespaces, for example)
… a big problem in the library community, for example
… perhaps we might lose some traction with groups that do care about the distinction (in favor of the folks who dont)
… for example, the identifier discussion plays right into this in many ways
… maybe start with the distinction and then drop later. (easier than other way)

Ivan Herman: where are the places where the differentiation matters?
… identifiers is very important!
… locators is also a place (since we mean IRI but folks look for URLs)
… so when we talk about some of these, we may indeed want to use the IRI term. but exception and not rule
… but URL is the norm

Katie Haritos-Shea: +1

Baldur Bjarnason: +1

Romain Deltour: +1

Tim Cole: +1

Benjamin Young: +1

Garth Conboy: Still +1

Resolution #3: Use URL-s and use IRI/URI when it becomes strictly important

Leonard Rosenthol: +1 let’s use URL everywhere except where we explicitly need IRI

Bill Kasdorf: +1

Tim Cole: one last bit on this rathole
… having the concept of identifier in addition to address is useful

Ivan Herman: Extra Pull Request: https://github.com/w3c/wpub/pull/28

Tim Cole: I did a pull request that address many of these issues
… but left open others such as #27 (canonical identifier)
… and use both IRI and URL, clear to differentiate them.

Tzviya Siegman: Tim’s PR https://github.com/w3c/wpub/pull/28/commits/d766b1c60eee4b81406c6f1363f79744a8928ccf

Tim Cole: so maybe we can raise issues between now and then on the PR, but lets accept it

Tzviya Siegman: email vote

Laurent Le Meur: reading over the pull request, there is a canonical identifier which is persistent and immutable
… if a WP is moved to another server, then the URLs will all change. is this the same pub or not?

Ivan Herman: very existential issue that we can spend a year on

Chris Maden: This is exactly the point for distinguishing between identifiers and locators…

Ivan Herman: depending on the needs of the publisher and publication

Bill Kasdorf: +1 to cmaden2

Ivan Herman: but we shouldn’t say anything about this specifically in our docs

Laurent Le Meur: does the fact that the identifier is in the manifest impact this, since the manifest must change if the identifier changes?

Tim Cole: by having this, it leaves open the option of how to handle moving between servers
… and you don’t want to lose the ability to identify it
… of course, that’s up to the publisher as they may wish to lose the identify. so you need both

Laurent Le Meur: so then there is still a requirement that we change the locator w/o changing the identifier? and so this has technical implications

Baldur Bjarnason: lots of prior art in the web community around this - same problem that feeds (Atom, RSS, etc.) all had to deal with

Laurent Le Meur: perhaps this is better called a persistent identifier

Ivan Herman: the term is defined by saying it is persistent in the doc

Tzviya Siegman: next steps

Ivan Herman: need a resolution to close issue 27.
… then hand over PR to editor?

Resolution #4: Close issue 27, hand over the PR to the editor

Ivan Herman: everyone OK with that?

Laurent Le Meur: thanks @bigbluehat I like the PR, yes

Leonard Rosenthol: it would get more eyes in the main doc - so let’s accept it and review there

Katie Haritos-Shea: I have a question: must’s and should’s, for example the natural language. Why a should?

Avneesh Singh: Title is still under discussion.

Leonard Rosenthol: it’s already in the HTML docs, so why force duplication in the manifest?

Ivan Herman: that’s why it should, not a must - because it’s very important but not required there in the manifest

Deborah Kaplan: there is not universal agreement on this however
… and books that have no words, there are interesting exceptions
… so let’s just call it a should for now and move on
… but many people still argue on WCAG concerns

Ivan Herman: if someone could put in an explicit issue about this (should vs. must)

Leonard Rosenthol: @ryladog will do

Avneesh Singh: title is still under heavy discussion in github. Language hasn’t had as much (yet). The language is also important for discovery, the language was included in EPUB metadata. And we still need to discuss how to deal with metadata and if it should be inside manifest or outside. So, many things are not yet settled.

Tzviya Siegman: thanks everyone who is working on the document - please keep them coming
… if anyone new wants to help, let us know
… and if you want to learn about the tools (respec, github), we can help
… and don’t forget about TPAC!

Tzviya Siegman: https://www.w3.org/2017/11/TPAC/

Tzviya Siegman: be srue to book your hotel

3. Resolutions