Publishing Working Group Telco — Minutes

Date: 2017-08-07

See also the Agenda and the IRC Log

Attendees

Present: Ivan Herman, Wolfgang Schindler, George Kerscher, Avneesh Singh, Chris Maden, Rachel Comerford, Leonard Rosenthol, Tim Cole, Baldur Bjarnason, Ric Wright, Luc Audrain, Deborah Kaplan, Tzviya Siegman, Jun Gamou, Murata Makoto, Hadrien Gardeur, Benjamin Young, Dave Cramer, Bill Kasdorf, Brady Duga, Heather Flanagan, Reinaldo Ferraz, Ben Schroeter

Regrets: Matt Garrish, Hugh McGuire, Garth Conboy, Charles LaPierre, Laurent Le Meur, Peter Krautzberger, Vladimir Levantovsky, Mateus Teixeira

Guests:

Chair: Tzviya Siegman

Scribe(s): Chris Maden

Content:

George Kerscher: Dave I could call you and patch you in. Give me a number to call.

Ric Wright: I always use the app, not the browser

1. approval of minutes

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

Tzviya Siegman: minutes approved with no objection

Resolution #1: last week’s minutes approved

2. tpac is in november

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

Tzviya Siegman: SalesForce is meeting in SF same time; get your hotel NOW.

Heather Flanagan: I have to book 6-8 months in advance; I already had to book over TPAC. :-(

3. welcome new members

Tzviya Siegman: no new members present.

4. Can a publication change over time? (consensus)

Tzviya Siegman: https://lists.w3.org/Archives/Public/public-publ-wg/2017Jul/0084.html

Tzviya Siegman: Leonard comments, quoting Garth; see list archive.

Ivan Herman: https://lists.w3.org/Archives/Public/public-publ-wg/2017Jul/0289.html

Ivan Herman: I made a proposal which seemed to be OK. (linked above)

Hadrien Gardeur: +1

Leonard Rosenthol: +1

Tzviya Siegman: Is there consensus on Ivan’s summary?

Tim Cole: +1

Brady Duga: +1

Ric Wright: +1

Wolfgang Schindler: +1

Deborah Kaplan: +1

(ivan) Proposed resolution: WG will not deal with this problem, and acknowledges the fact that it cannot really control the changes of the WP’s constituent resources

Jun Gamou: +1

Benjamin Young: +1

Luc Audrain: +1

Bill Kasdorf: +1

Leonard Rosenthol: It may be worth noting somewhere in the document that this is a true statement.

Ivan Herman: This is a resolution, will be recorded in the minutes.

Resolution #2: WG will not deal with this problem, and acknowledges the fact that it cannot really control the changes of the WP’s constituent resources.

Ivan Herman: Also in that mail, there are a number of things which may need to be addressed in a separate Note, good practice on publishing e.g..

Wolfgang Schindler: +1 to best practices note

Tzviya Siegman: We may end up doing a best-practices, or recommending another group do so.

5. Working definitions from Publishing and Linking - Can we agree to link to these definitions for working draft, so that we have terms to work with?

Tzviya Siegman: https://www.w3.org/TR/publishing-linking/#terminology

Tzviya Siegman: It may be helpful to just point to that for our initial definitions.

Rachel Comerford: +1

Ivan Herman: +1

Tzviya Siegman: +1

Chris Maden: +1

Baldur Bjarnason: +1

Wolfgang Schindler: +1

Benjamin Young: +1

Deborah Kaplan: +1

Tim Cole: +1

Leonard Rosenthol: +1

Hadrien Gardeur: +1

Jun Gamou: +1

Ric Wright: +1

Luc Audrain: +1

George Kerscher: +1

Reinaldo Ferraz: +1

Marisa DeMeglio: +1

Bill Kasdorf: +1

Resolution #3: the draft will use the definitions of https://www.w3.org/TR/publishing-linking/#terminology

Tzviya Siegman: Working definitions: consensus.

Bill Kasdorf: Plus we should not DEPART from those definitions

6. Identifiers/locators

Tim Cole: Some conversations between me and Benjamin on how to start with this topic. Started with straightforward ideas; proposed addition to terminology section.

Ivan Herman: relevant PR in github: https://github.com/w3c/wpub/pull/17

Tim Cole: Put that in a pull request (linked above). Should the PR move forward, be changed?

Ric Wright: Does it make sense to add the definitions document to the wiki reading list?

Ivan Herman: Proposed version: https://rawgit.com/tcole3/wpub/8b3d570bb3c2106e2fc754119369bd4a434067f3/index.html

Tim Cole: What should this look like if added to the document?

Tim Cole: IRI, canonical identifier, locator definitions added.

Tim Cole: Those are in §1.6. In §3.2.1, WP should be assigned a canonical identifier, with some constraints given.

Tim Cole: Questions. Is IRI the right thing to use?

Murata Makoto: I have a mixed feeling.

Ivan Herman: Issue on IRI vs URL: https://github.com/w3c/publ-wg/issues/21

Leonard Rosenthol: I agree that IRIs are better than URLs, but it’s a hot and fiercely-debated topic within W3C. We are going to get pushback if we go down this path.

Ivan Herman: On a process level, maybe we could separate this; URL/IRI thing is general for all our documents everywhere, could be set aside and considered separately.

Murata Makoto: If some people think IRI is wrong, what is right?

Tzviya Siegman: Let’s come back to this.

Luc Audrain: We have already started working on the metadata part, and depend on this.

Tzviya Siegman: Do we have other feedback on Tim’s proposal?

Tim Cole: The idea of a canonical identifier: how important is it for a WP to have that? Is it practical? Is it should/must? Must it be resolvable?

Tim Cole: If resolvable, does it point to the manifest, landing page, something else?

Ivan Herman: We had some preliminary discussion… Ideal world vs. reality. In an ideal world, I would say a WP must have at least 1 identifier, but in discussion, made clear that this will not happen.

Ivan Herman: So we say a WP should have at least one identifier. We also said the identifier should be mapped to a locator.

Murata Makoto: +1

Ivan Herman: And maybe some paragraphs about why you really really should have an identifier.

Tim Cole: We said an identifier must resolve.

Tzviya Siegman: If we don’t say must have identifier, then what is the WP doing on the Web? It’s not really on the Web if it doesn’t have an identifier.

Tim Cole: Identifying IRI concept comes from here: http://signposting.org/conventions/

Bill Kasdorf: Agree with Tzviya, identifier must be able to be expressed as a locator. But if there is no locator, how is it a WP?

Tzviya Siegman: I said identifier, not locator.

Bill Kasdorf: Yes, sorry—must have identifier, must be able to be expressed as a locator.

Ivan Herman: No… we separate the locator and the identifier, we are talking only about the locator now. Lack of identifier doesn’t mean it doesn’t have a locator, doesn’t mean it’s not on the Web.

Luc Audrain: +1

Murata Makoto: So, URN?

Ivan Herman: If I transfer it, the identifier doesn’t change; a simple WP may be moved around, locator changes, but is still a WP.

Tim Cole: Identifier implies persistence; URL may change

Murata Makoto: I believe that URI = URL + URN

Deborah Kaplan: In traditional publishing terms: a locator acts like a URL, but an identifier is more like an ISBN.

Ivan Herman: correct

Benjamin Young: MURATA: sadly not… a URN is a URI…but not a URL

Baldur Bjarnason: Separation b/t identifier/locator is not specific to publishing industry. Important in ATOM syndication.

Baldur Bjarnason: Not just an academic/LIS thing, but practical for determining equivalence.

Tzviya Siegman: Back to Tim’s proposal: locator is a must, identifier is a should. Agreement?

Murata Makoto: Benjamin: I know that a URN is not a URL, but it is a URI

Hadrien Gardeur: +1 but I still think that we should default to using the locator as the identifier

Benjamin Young: MURATA: right. I think I just misunderstood the intent of the “math” earlier…appologies

Tim Cole: Use case is a single WP located multiple places. Might have 5 locators, but should have 1 identifier; else I can’t refer to it universally. DOI has workarounds, but they hinge on a single identifier.

Tim Cole: But if I want to just put up a single-page publication, I need to take advantage of that should.

Tzviya Siegman: I need to point out that we are explicitly not solving the “work identifier” problem (e.g., an identifier for Moby Dick generally).

Leonard Rosenthol: I understand the use for should or shall on identifiers, but there are cases where there is no such identifier. Or rather, no mechanism by which the author can choose one.

Ivan Herman: Hence the should.

Bill Kasdorf: I like the way Tim handled this in the proposal. The locator is not a must; the identifier (which is a should) must enable retrieval of the manifest.

Luc Audrain: Locator is pre-existent, before identifier. When you publish, you give locator. Identifier is secondary. Very simple WP can be referred to by URL; so anyone can publish WP. In certain communities (ebooks, journals), need identifier; but for simple WP, URL is given and suffices. Would be more complicated to require identifier.

Tim Cole: Proposal right now seems premature; should correct for the identifier, but mention of locator needs to be corrected. Benjamin and I will withdraw this, modify, and propose by next week.

Tim Cole: Will say locator is must, identifier is should, if identifier exists, must map to locator.

Benjamin Young: Anything on the Web will have a locator (by virtue of being on the Web). WPs, pre-publication, may not have their locations known.

Bill Kasdorf: thanks, Ben, that’s a good point

Murata Makoto: I am wondering if the def of “Web Publication Canonical Identifier” should mention locators.

Luc Audrain: process point is interesting

Benjamin Young: Consider if our revision process happened not on GitHub, but off-Web—no locator for those.

Benjamin Young: We should make space for identifiers and locators, and allow publishers to use either.

Ivan Herman: What we have here for identifiers is OK to go into document. We don’t talk about locator; we should, but don’t have to yet.

Benjamin Young: +1 to moving forward with what Tim’s written–to keep the trains moving, etc :)

Tzviya Siegman: Tim wants to clean up the proposal; group would be happy to merge as-is, then clean up, or clean up first; whichever.

Bill Kasdorf: +1

Tim Cole: If there’s consensus to merge now, that’s fine.

Resolution #4: The PR #17 can be merged with some extra cleanup from Tim either before or after the PR

Tzviya Siegman: Other task forces can follow this model.

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

Tim Cole: And it’s probably helpful not to put too much into a single PR.

7. Minimum Viable Manifest

Ivan Herman: https://github.com/w3c/wpub/issues/15

Tzviya Siegman: Lots of comments. What is the minimum for a manifest? We can add more later, as we understand more about what WPs are.

Tzviya Siegman: Dave thinks there are three things a manifest needs: a list of resources, an order, and an assertion of WP-ness.

Tzviya Siegman: (correction): List of resources in order, a title, and assertion of WP-ness.

Hadrien Gardeur: There is a difference; assertion of WP-ness can just be through assertion of media type for manifest. We always include a self link, a canonical URL for the manifest.

Hadrien Gardeur: Whether we need a URL for the manifest in the MVM, depends on other factors. If manifest is distributed over HTTP, then URL is provided, but if discovered through other channels, we need some way to give the URL in the document itself.

Benjamin Young: leonardr: empty title’s don’t validate in HTML5

Benjamin Young: https://validator.w3.org/nu/#textarea

Leonard Rosenthol: Reiterating from comment thread: I don’t consider title an MVM item. If required, people will put in null titles, so it’s useless. Tried it in some PDF standards, and found spaces or emptiness.

Ivan Herman: version proposed by dauwhe: https://github.com/w3c/wpub/issues/15#issuecomment-320699295

Chris Maden: MURATA; ebook 3, list all resources, even not spine items. Here, proposal mentions only primary resources; is that intentional? We won’t list secondary resources in manifest?

Leonard Rosenthol: @tzviya - yes, validation can check that, but what happens is that users don’t validate things before distributing them.

Bill Kasdorf: Makoto, I see that as a distinction between WP and EPUB 4

Tzviya Siegman: That is the proposal now, yes.

Dave Cramer: Yes, this is intentional.

Dave Cramer: There are situations where some reading systems might require full enumeration, but everything on the Web doesn’t need it.

Romain Deltour: +1 to dauwhe

Avneesh Singh: A11y aspect: What is essential navigation, what is optional? Have heard comments that browser will not be able to do this or that; WCAG is not just about browser capabilities. Assistive technology should enable discovery of information.

Avneesh Singh: §2.4.5 deals with more than one way to access content, §2.4.7, user should be able to identify where they are. If we rely on default reading order, we miss out the hierarchy, can’t be reconstructed from reading order. Navigation must remain as an essential component of the manifest. Keep it in the essentials, unless/until we discover that some other mechanism can fulfill this.

Tzviya Siegman: Are you saying that navigation document should be in the minimal requirement?

Avneesh Singh: yes.

Tzviya Siegman: OK, but we are talking about the minimal viable manifest. Navigation is not in the absolutely minimal manifest.

Dave Cramer: 3 quick responses: Hadrien: If there is a unique media type for the manifest, that satisfies that issue, but we may not have consensus on that. Leonard: Yes, there are untitled documents, but this is the publication WG, not the document WG. Publications need titles. Avneesh: We are still exploring the idea that a nav document could be the way to provide that.

Ivan Herman: To Dave’s last comment: There might be other ways to find out the reading order, but this is the same as whether we use media type or not. What is the minimum needed for the manifest, abstractly?

Ivan Herman: We were bitten in the Web manifest doc, extension mechanism is needed. Minimum manifest can not be completely closed.

Leonard Rosenthol: @dauwhe - yes, but consider formal vs. ad-hoc publications

Tzviya Siegman: Some amount of metadata is needed.

Deborah Kaplan: If an issue arose here and in GitHub, where to respond?

Tzviya Siegman: here is fine.

Deborah Kaplan: There is not a single spec from W3C that people don’t implement incorrectly. That’s not a good argument not to require things, even though they’ll be broken.

Ivan Herman: +1 to dkaplan3

Hadrien Gardeur: I hear you, Ivan, but if we discuss the manifest truly in abstract, what is the boundary of what we should define? We need a locator for the manifest in the list of abstract things we need. Is a11y something part of a conceptual abstract model, or a design principle?

Tzviya Siegman: We are no longer talking about the abstract model, but what we should put in our draft defining the manifest

Tzviya Siegman: Had hoped to close this issue today, but we apparently still need to pick the items for the MVM. I think some consensus is possible.

Tzviya Siegman: We need a list of primary resources. (Everyone agrees we need list of resources, not everyone agrees primary resources.)

Bill Kasdorf: +1 to list of primary resources

Deborah Kaplan: +1

Rachel Comerford: +1

Murata Makoto: +1

Luc Audrain: +1

Baldur Bjarnason: +1 list of primary resources

Brady Duga: +1

Hadrien Gardeur: +1

Wolfgang Schindler: +1

Leonard Rosenthol: +1 to list of primaries

Tzviya Siegman: Consensus: We need a list of at least primary resources.

Dave Cramer: +1

Romain Deltour: +1

Bill Kasdorf: -1 on secondary resources because they are more likely to change

Murata Makoto: +1

Benjamin Young: +1

Bill Kasdorf: +1 on WP-ness

Tzviya Siegman: There needs to be some method of asserting WP-ness, though we haven’t agreed how.

Luc Audrain: +1

Leonard Rosenthol: +1 on identification (in some way)

Hadrien Gardeur: +1 for WP-ness after Ivan’s comment

Deborah Kaplan: +1

Brady Duga: @bill_kasdorf Please comment on the bug

Wolfgang Schindler: +1 on WP-ness

Baldur Bjarnason: +1 on WP-ness

Romain Deltour: +1

Tzviya Siegman: Those two things have consensus, but no more. By next week, we need to nail down MVM.

Baldur Bjarnason: I agree with leonardr on titles

Rachel Comerford: +1 title required

Chris Maden: ivan/tzviya: Leonard is only dissenter on title.

Chris Maden: others support Leonard

Tzviya Siegman: Reminder: GitHub is where the action is. If you aren’t watching repos, you’ll miss notifications.

Leonard Rosenthol: thanks @baldur!

Chris Maden: adjournment

8. Resolutions