Publishing WG Telco — Minutes

Date: 2017-07-31

See also the Agenda and the IRC Log

Attendees

Present: Ivan Herman, Wolfgang Schindler, Tzviya Siegman, Rachel Comerford, George Kerscher, Reinaldo Ferraz, Romain Deltour, Avneesh Singh, Peter Krautzberger, Matt Garrish, Jun Gamou, Deborah Kaplan, Ric Wright, Bill Kasdorf, Benjamin Young, Leonard Rosenthol, Greg Albers, Harriett Green, Brady Duga, Charles LaPierre, Tim Cole, Hugh McGuire, Leslie Hulse, Hadrien Gardeur, Mateus Teixeira, Yuri Kharmov

Regrets: Garth Conboy, Laurent Le Meur, Chris Maden

Guests:

Chair: Tzviya Siegman

Scribe(s): Romain Deltour

Content:

Wolfgang Schindler: hi to all!

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

Tzviya Siegman: any comments on the minutes?

Resolution #1: minutes accepted

Tzviya Siegman: minutes approved!

Tzviya Siegman: we have some new member, who are here for the 1st time, please introduce yourself

greg: Greg Albers, from Getty in LA
… doing some web publication, open access publication, excited to be part of this!

Harriett Green: Harriett Green, from UIUC

renaldo: Renaldo Ferraz, working with web publication, background on open web technologies and accessibility

Tzviya Siegman: we discussed a lot the definition of WP and other terminology

1. terminology issues

Tzviya Siegman: some of the terms are defined in the charter

Tzviya Siegman: https://w3c.github.io/wpub/#terminology

Tzviya Siegman: Matt provided some working definition in the draft
… let’s take 5 minutes to go through the terminology
… the basic definition is the WP definition
… current definition reads:

Romain Deltour: A Web Publication is a collection of one or more primary resources, organized together through a manifest into a single logical work with a default reading order. The Web Publication is uniquely identifiable and presentable using Open Web Platform technologies.

Tzviya Siegman: let’s vote, +1 / -1

Wolfgang Schindler: +1

Tzviya Siegman: +1

Matt Garrish: +1

Deborah Kaplan: +1

Bill Kasdorf: +1

Ric Wright: +1

Leonard Rosenthol: +1

Peter Krautzberger: +1

Jun Gamou: +1

Harriett Green: +1

Ivan Herman: +1

Greg Albers: +1

Benjamin Young: +1

Rachel Comerford: +1

Romain Deltour: not sure about “uniquely” vs “unambiguously”

Resolution #2: the working definition for the FPWD for a WP is: “A Web Publication is a collection of one or more primary resources, organized together through a manifest into a single logical work with a default reading order. The Web Publication is uniquely identifiable and presentable using Open Web Platform technologies.”

Romain Deltour: but +1 from me

Tzviya Siegman: we can’t change the charter, any issue?

Ivan Herman: I dont’t think so

Tzviya Siegman: A manifest represents structured information about a Web Publication, such as informative metadata, a list of all primary and secondary resources, and the default reading order.

Bill Kasdorf: on default reading order, I’d change “static” to “specific” but I won’t bring this up for discussion now ;)

Greg Albers: +1

Leonard Rosenthol: -1

Romain Deltour: +1

Tzviya Siegman: +1

Matt Garrish: +1

Wolfgang Schindler: +1

Jun Gamou: +1

Ivan Herman: +1

Tim Cole: +1

Benjamin Young: +1

Peter Krautzberger: +1

Harriett Green: +1

Brady Duga: +1

Rachel Comerford: +1

Bill Kasdorf: +1

Charles LaPierre: +1

George Kerscher: +1

Leonard Rosenthol: I guess it’s minor. Concerned about “such as” meaning that all are present and in the manifest
… we’ve not decided about that
… I agree with the concept, but the wording may be too explicit for now

Tzviya Siegman: I suggest you propose an alternate wording

Bill Kasdorf: “such as” specifically means “may or may not be included.”

Ivan Herman: nothing here is final, it’s only for FPWD, we can amend that later

Leonard Rosenthol: a small change may make everybody happy

Leonard Rosenthol: A manifest represents structured information about a Web Publication. This may include informative metadata, a list of all primary and secondary resources, and the default reading order.

Brady Duga: we can maybe clarify after the definition, to avoid crafting the ultimate definition

Leonard Rosenthol: see the suggested wording above

Bill Kasdorf: I’d argue that they’re saying the same thing, so sure, okay by me.

Hadrien Gardeur: “all” secondary resources

Hugh McGuire: can someone post the link to the doc we are working on? I can’t find

Hadrien Gardeur: not sure we can always have them all

Hugh McGuire: thanks

Tzviya Siegman: https://w3c.github.io/wpub/#terminology

Leonard Rosenthol: @hadrien - that’s why I like my “may include”

Matt Garrish: no specific comment. I used “such as” because it’s not finalized. a note for the terminology section as a whole, saying there are working definitions and subject to change

Bill Kasdorf: +1 to what Tzviya just said

Tzviya Siegman: I prefer this approach. again, we’re trying to move forward, not craft something that’s perfect

Charles LaPierre: this may include items such as… ?

Leonard Rosenthol: we all agree about the first part. but we haven’t agreed on what’s gonna be in the manifest, what goes there and what goes somewhere else. the definition is the first part.

Tzviya Siegman: I’m concerned that we’re getting caught up in details

Ivan Herman: s/the working definition for the FPWD is:/the working definition for the FPWD for WP is:/

Tim Cole: We want to be careful about the use of ‘may’ since this has specific meaning in the context of specs. So I prefer working definition.

Tzviya Siegman: consensus is not unanimity

Deborah Kaplan: +1 for moving forward

Bill Kasdorf: +1

Benjamin Young: +1

Tzviya Siegman: we can move forward as is, with a caveat that this is a working definition

Resolution #3: the working definition for the FPWD for manifest: “A manifest represents structured information about a Web Publication, such as informative metadata, a list of all primary and secondary resources, and the default reading order.”

Avneesh Singh: prese+1 to move forward

Wolfgang Schindler: +1 for moving forward

Peter Krautzberger: +1

Charles LaPierre: +1

Tzviya Siegman: Matt, are the other definitions ready for approval?

Leonard Rosenthol: +1 to move forward

Matt Garrish: yes, should be. these are standard pieces

Tzviya Siegman: The default reading order is the static progression through the primary resources defined in the manifest by the creator of a Web Publication.

Tzviya Siegman: A user might follow alternative pathways through the content, but in the absence of such interaction the default reading order defines the expected progression from one primary resource to the next.

Tzviya Siegman: the default reading order is the static progression through the primary resources defined in the manifest by the creator of a Web Publication.

Romain Deltour: A user might follow alternative pathways through the content, but in the absence of such interaction the default reading order defines the expected progression from one primary resource to the next.

billk: ???

Tzviya Siegman: let’s vote

Romain Deltour: +1

Bill Kasdorf: +1

Greg Albers: +1

Wolfgang Schindler: +1

Brady Duga: +1

Tzviya Siegman: +1

George Kerscher: +1

Deborah Kaplan: +1

Benjamin Young: +1

Jun Gamou: +1

Matt Garrish: +1

Tim Cole: +1

Reinaldo Ferraz: +1

Leonard Rosenthol: +.05

Peter Krautzberger: +1

Harriett Green: +1

Rachel Comerford: +1

Charles LaPierre: s/???/ change static to precise

Charles LaPierre: +1

Ivan Herman: +1

Hugh McGuire: +1

Hadrien Gardeur: yup, static is confusing

Tzviya Siegman: no -1, Charles and Bill will propose a change about “static”

Resolution #4: the working definition for the FPWD for reading order: “The default reading order is the static progression through the primary resources defined in the manifest by the creator of a Web Publication. A user might follow alternative pathways through the content, but in the absence of such interaction the default reading order defines the expected progression from one primary resource to the next.”

Leonard Rosenthol: remove the reference to “defined in the manifest” to remove the circular reference

Tzviya Siegman: not sure I agree but we’ll look into it

Tzviya Siegman: A primary resource is a resource listed in the default reading order of a Web Publication.

Tzviya Siegman: A primary resource typically references many secondary resources necessary for it to be correctly processed and rendered (e.g., style sheets, scripts, multimedia files).

Tzviya Siegman: before we do the vote, there were many discussion in emails

Ivan Herman: +1

Tzviya Siegman: +1

Tzviya Siegman: again, quick vote, and we can do work later if need be

Wolfgang Schindler: +1

Deborah Kaplan: +1

Bill Kasdorf: +1

Romain Deltour: +1

Charles LaPierre: +1

Matt Garrish: +1

Benjamin Young: +1

Tim Cole: +1

Jun Gamou: +1

Ric Wright: +1

Greg Albers: +1

Brady Duga: +0

Rachel Comerford: +1

George Kerscher: +1

Avneesh Singh: +1

Peter Krautzberger: +1

Harriett Green: +1

Leonard Rosenthol: +1

Reinaldo Ferraz: +1

Resolution #5: the working definition for the FPWD for primary resource: “A primary resource is a resource listed in the default reading order of a Web Publication. A primary resource typically references many secondary resources necessary for it to be correctly processed and rendered (e.g., style sheets, scripts, multimedia files).”

Tzviya Siegman: Brady, why +0?

Leonard Rosenthol: +1 to Brady :)

Brady Duga: I think it’s too vague, but I’m ok to move forward. are images primary resources, is it only HTML?

Tzviya Siegman: I wonder why you’re fine with it if you don’t understand the definition, but ok

Peter Krautzberger: there was discussion that multimedia files can easily be primary.

Benjamin Young: agree with Brady’s concerns, but also would like to move on to building/writing…and then revisit the definitions

Brady Duga: I don’t have a better thing to replace it with

Matt Garrish: would it make sense to say “may reference” instead of “typically” ?

Brady Duga: one of the reason I don’t have a good replacement is that we’ve not discussed what is a primary resource yet

Hugh McGuire: let’s make a list of things that might be primary resources… and then decide?

Matt Garrish: yes, it’s vague at this point, but fills in a gap for now.

Jeff Printy: Hello, I’m an a11y developer from Macmillan Learning

Jeff Printy: Jeff, I’m one of the devs from Macmilan, focusing on a11y

Hugh McGuire: fun!

Hadrien Gardeur: Yuri is from Evident Point

Ric Wright: Yuri Khramov

Yuri Khramov: Yuri Khramov, from Evident Point, working on Readium (1 & 2), founder of Evident Point

Hadrien Gardeur: primary = in the reading order

Leonard Rosenthol: going back to the def, I’m fine going forward with the def. I don’t think the format of primary resource is gonna be a problem, but we need to understand conceptually what is primary and secondary

Hugh McGuire: +1 to hadrien

Wolfgang Schindler: +1 to hadrien

Leonard Rosenthol: @hadrien - the problem is that you then get a circular reference :(

Hugh McGuire: in general I liked the conversation about using bullet list to understand what can be primary resources. I suggest we do that after we approve on the working definition

Leonard Rosenthol: and I think can think of things that are primary but not necessary in the default RO

2. web packaging spec

Tzviya Siegman: reminder that Matt is the only one who actually proposed some editing, so please propose some wording

Hadrien Gardeur: @leonardr I’m not fully convinced that we need two definitions, this would avoid the circular nature of it

Tzviya Siegman: some people from Google have been working on a fork of the Packaging spec

Bill Kasdorf: secondary = a resource not in the primary reading order but referenced from a resource in the primary reading order

Tzviya Siegman: there’s a standard way to save a related set as HTTP responses
… [see other steps in an email]
… Jeffery will likely join us for a meeting in a few weeks
… we need to set up use cases to make it obvious that the specification will be useful to anybody

Leonard Rosenthol: we should clarify something, I talked to Adobe IETF representatives
… all that took place was Jeff giving a presentation on his ideas

Tzviya Siegman: there’s a lot of discussion, we know it’s not decided

Leonard Rosenthol: there is still a belief that splitting it up to 2 separate [no audio]
… my understanding is that it’s not a done deal

Tzviya Siegman: I was just summarizing what the current proposal is, and that we’ll have a meeting with Jeffrey

Leonard Rosenthol: we as a group should take a position on what we want to have

Ivan Herman: honestly, I read that email and I don’t understand it
… I don’t know where this work is going and whether it’s relevant for us
… until we have a meeting and get a clearer view, I can’t tell
… this is more heading towards caching, which is not necessarily what we’re interested in. I have no position since I don’t understand it yet

Benjamin Young: we also have these use cases as a guideline when considering packaging formats http://w3c.github.io/dpub-pwp-ucr/#pwp

Tzviya Siegman: hopefully we’ll get clarity with the meeting

Brady Duga: we don’t have the data to back up a position, so we need the data first
… then we can define what is our position
… my understanding it matches fairly well what we want, but we should wait for the meeting with Jeffrey

3. Identifier and locators

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

Tzviya Siegman: if you didn’t have a chance to follow the entire thread, that’s understandable
… let’s take a look at where we’re going, and hash out what we want to accomplish with it
… Tim and Benjamin are experienced with locators, BillK on identifiers, etc.

Tzviya Siegman: quoting the email:

Romain Deltour: - a publication has a manifest, which is addressable (it has a URL)

Romain Deltour: - a publication has HTML content (“primary resources”, it seems), which is addressable (each primary resource has a URL)

Romain Deltour: - assuming that the manifest is an external non-HTML document (read JSON), its URL is different from any of the URLs to the HTML content.

Bill Kasdorf: lots and lots of different identifiers
… we’re looking for a unique identifier for WP, my position is that it s/b an addressable identifier

Romain Deltour: [poor audio quality]

Hadrien Gardeur: +1 for what Bill just said

Bill Kasdorf: fundamentally, I’d like to see an identifier aligning with Web standard, and I think this identifier s/b agnostic to the serialization of the manifest

Tim Cole: there’s gonna be a difference between identifier and locator
… it’s not unreasonable that identifier can be used by machine and human agents, they can be the same, but you don’t have to. A human cannot read JSON, a machine can
… in terms of locators, the main lesson from the Web Annotation was that understanding that we want to identifiy content that may appear in different locations
… or provide a way to point to ??? or allow both

Bill Kasdorf: +1 to identifying content that may appear in different locations

Tim Cole: a number of sub discussions have to get started

Ivan Herman: when I have an identifier and want to map it to something to dereference it, the question is what do I dereference it to?
… then it can be either the manifest, or HTML, etc
… not sure that we need to define that
… we need to define the mechanism that UA can use
… in some situations people will have the ability to set up content negotiation
… but not everyone is able to set it up
… we had some thoughts about that in the IG, whereby we setup an algorithm saying that there are diffferent ways
… I’m not sure we should specify one and only one among all these
… at the end of the route we have to get to a manifest, but there may be different possibilities

Tzviya Siegman: one of my concern is that when we’re talking about what our identifier should be it comes down to serialization
… the question is: what’s the identifier for a WP?
… then we need to log subquestions to move on

Bill Kasdorf: I prefer to define clearly what do we need this identifier to be

Wolfgang Schindler: identifier as globally unique ID descriptor for a WP

Bill Kasdorf: the other point, is that I’d actually postpone the dereferencing issue to after we define what the manifest will look like
… what do we need to be agnostic about?

Tzviya Siegman: we can use a Google doc to get it started

Bill Kasdorf: OK, I’ll do that

Romain Deltour: I agree with Bill that we need to agree on what the identifier is gonna be used for, before even trying to define what it looks like

Benjamin Young: And we need to answer questions like “is the identifier also a locator”–or just a unique-ifier ;)

Tzviya Siegman: I have a document that I can share, but Bill you can start a new one
… any other comments?

Tzviya Siegman: document with requirements from github: https://docs.google.com/document/d/1NzYLURq4zqkeGoCJbY-5rlIUsfPt9Dy5S10BLOA-tGg/edit?usp=sharing

Benjamin Young: or…we at least need to have a list of those questions with pro/cons

Ivan Herman: the question from Benjamin on IRC is very relevant

Romain Deltour: +1

Benjamin Young: [muted]

Ivan Herman: If I’m talking about identifier, it just uniquely identifies a thing in the wild
… it can be mapped to a locator, and via that route can be used to find a document on the Web
… DOI is a good example. there’s a clear way set up by the scholarly publishing community to go from a DOI to a Web page
… we need a clear mind on whether we need an identifier mappable to a locator or not

Tim Cole: whatever we come up for an identifier, we have to identify structures
… we can start enumerating the kind of identifiers used in publications today

Ivan Herman: the charter says explicitly we are not chartered to come up with a new identifier scheme
… but we have to be able to answer the issue eventually
… we can’t list all the existing identifiers

Hadrien Gardeur: +1 with Ivan for both points

Bill Kasdorf: just to clarify even a DOI is not a crossref DOI, there are other uses
… there are DOI for movies, videos, etc
… we need to be agnostic about those things
… they’re outside of our scope IMO

Ivan Herman: I agree, and we get back to the question that we’ve asked ourselves in the IG
… essentially, we have to answer what happens when we dereference the identifier

Benjamin Young: [still muted]

Romain Deltour: not even convinced we need the identifier to be addressable, we need to talk about that first

Leonard Rosenthol: I agree with Romain on that one, we’re getting identifiers and locators backwards
… identifiers have nothing to do with dereferencing

Ivan Herman: I agree the identifier itself doesn’t need to be dereferencable, but the identifier can be mapped to a locator, and we have something to say about what it maps to
… [describes the DOI use case]
… we have to say what is that represents the WP

Bill Kasforf: all the identifiers can refer to a physical thing that is [poor audio quality, sorry :/]

Tzviya Siegman: 4 mins left, a bunch of people signed up to write some sections

4. FPWD contribution status

Bill Kasdorf: thanks, Benjamin!

Tzviya Siegman: once again, what do you need from us to get started, what’s missing?

Greg Albers: Are the sections and volunteers listed somewhere?

Tzviya Siegman: if you have questions about how to use gh or ReSpec, I’m available, Ivan is available

Hugh McGuire: we (rebus = boris, baldur & I) will be drafting something to send to Luc tomorrow. Then we’ll talk, & hopefully be ready to publish something.

Tim Cole: mostly for Matt: should we do pull requests?

Hugh McGuire: re: metadata

Matt Garrish: just right straight in

Ivan Herman: at the moment only a few people have direct edit rights, only those officially nominated as editors
… so you have to go through the pull request mechanism at this point

Tim Cole: the ability to make issue labels would be nice

Ivan Herman: if you can’t, you know where to find me!

Deborah Kaplan: +1 Tzviya feeling better

Tzviya Siegman: thank you, have a good week!

5. Resolutions