Publishing Working Group Telco — Minutes

Date: 2019-10-21

See also the Agenda and the IRC Log

Attendees

Present: George Kerscher, Mateus Teixeira, Ivan Herman, Deborah Kaplan, Matt Garrish, Teenya Franklin, Dave Cramer, Ric Wright, Avneesh Singh, Franco Alvarado, Juan Corona, Ben Schroeter, Marisa DeMeglio, David Stroup, Charles LaPierre, Geoff Jukes, Benjamin Young, Bill Kasdorf, Brady Duga, Gregorio Pellegrino

Regrets: Wendy Reid, Garth Conboy, Luc Audrain, Romain Deltour, Rachel Comerford, Nellie McKesson

Guests:

Chair: Matt Garrish

Scribe(s): Mateus Teixeira

Content:

Matt Garrish: https://www.w3.org/publishing/groups/publ-wg/Meetings/Minutes/2019/2019-10-14-pwg

Matt Garrish: first step, approve minutes…
… minutes approved

Resolution #1: last week’s meeting approved

1. Open Issues

1.1. single localizable string #115

Matt Garrish: https://github.com/w3c/pub-manifest/issues/115

Matt Garrish: moving on to real topics of the day … first issue re publication manifest, issue 115, localizable strings… some minor issues have come up… just want to make sure the solutions make sense to the group
… a question of two properties… removing requirement for single values, allowing multiple languages in an array

Deborah Kaplan: the solution to make it an array makes perfect sense

Matt Garrish: the use of localizable strings works with schema.org, provides for multiple languages

Ivan Herman: correct, these have several values out of the box in schema.org… we don’t have to do anything

Matt Garrish: it’s not something that in EPUB we’ve gone into doing (multiple language a11y summaries, for example)
… we’re not breaking anything or deviating
… seems like we can resolve this

Proposed resolution: the accessibilitySummary and description properties accept arrays of strings (Ivan Herman)

Deborah Kaplan: +1

Ivan Herman: +1

Geoff Jukes: +1

Matt Garrish: +1

Mateus Teixeira: +1

George Kerscher: +1

Marisa DeMeglio: +1

Avneesh Singh: +1

Dave Cramer: +.9

Ben Schroeter: +1

Ric Wright: +1

Dave Cramer: i wonder about implicitly endorsing a design choice that every given language of a work should be in the same publication

Matt Garrish: but i don’t think we should exclude this from the possibilities

David Stroup: +1

Matt Garrish: if you need it, it’s there

Dave Cramer: yep, that’s fine

Resolution #2: the accessibilitySummary and description properties accept arrays of strings

1.2. Presence of id should be a SHOULD? #112

Matt Garrish: https://github.com/w3c/pub-manifest/issues/112

Matt Garrish: next issue… 112, raised by ivan… when we took out web publications, we also reduced our recommended property list… a few requirement remain, everything else became optional
… should we continue to recommend the presence of id and type? they are not strictly necessary… do you agree, disagree?

Dave Cramer: some concerns about increasing authoring burden in order to satisfy requirements of RFD processing…
… “i make the webpage, don’t have to come up with an id”

Matt Garrish: yes, and certainly why they’re not required… alternatively, we could put it into best practices
… explain why it’s useful to have them

Benjamin Young: this is also where we put canonical identifiers using JSON-LD, even if you process just as JSON, you’d want to have an id there… if I put a bunch of stuff in a bag, I want to have an identifier for that… it should be important for publishers to name your stuff

Ivan Herman: two things—on type, schema.org processors are dependent on the type of the JSON contents as a whole…
… when I use the testing tool they offer, the absence results in a bunch of errors…
… regarding id, I agree with dauwhe that it should not be required… the question is whether we should make it very difficult to use… the way I tested it, i ran the manifest through a JSON-LD processor which produced RDF triples… to see what really happens…
… that’s when I realized that there is nothing that identified the resource as a whole thing

Benjamin Young: related to what ivan said… schema.org with its type injection…. would seem to keep it in the recommended space
… the other thing that drives considerations of id is that, it is usually embedded in HTML pages, and processors will give the identifier of the document you got it from
… this would also happen with publication manifest inside a web page
… so ids in audiobook land may be another question… but it becomes a processing bungle, but it won’t catalog metadata correctly without id… as a machine, i won’t know i’ve seen it before…

Matt Garrish: there’s precedent in EPUB for unique identifier for a publication… i don’t think this would add any burden either way
… it’s complexity versus having a minimally viable manifest for what we’re expecting to be done with them… that’s the case for having them recommended
… should we put this to a vote?

Mateus Teixeira: anyone who can’t live with it?

Proposed resolution: id and type are RECOMMENDED properties (Ivan Herman)

Matt Garrish: +1

Geoff Jukes: +1

Ivan Herman: +1

Mateus Teixeira: +1

Benjamin Young: +1

Bill Kasdorf: +1

Ric Wright: +1

David Stroup: +1

Ben Schroeter: +1

Resolution #3: id and type are RECOMMENDED properties

Matt Garrish: we’ll make them RECOMMENDED properties, then

1.3. bounds of an audiobook #26

Matt Garrish: https://github.com/w3c/audiobooks/issues/26

Matt Garrish: next issue, 26, from audiobooks repository, opened by dauwhe
… . when we split apart pub manifest from audiobook, we don’t talk about bounds… the question is, is there more that we should say in the audiobook specification?

Dave Cramer: in the context of audiobooks, this seems kind of strange… how is the user agent going to be encountering audio resources that are not in the reading order or other resources?
… we’re essentially talking about a JSON with a list of things… and user agents are obliged to compare absolute URLs… i’m struggling to be able to test this to see what the goal of this section is… how it influences the behavior of audiobook readers/makers
… i’m not sure we need the whole section about bounds that we then don’t do anything with

Matt Garrish: i agree… bounds lose some of the interest when talking about packages, for example
… regardless of how interesting it is, a publication still have some bounds to it…

Dave Cramer: i just don’t see how the concept is useful… audiobooks are things, creations of humans, but those aren’t testable and don’t have impact on users or content creators… why have such a prominent position on the spec?

Matt Garrish: maybe the prominence is misplaced

George Kerscher: when there is a TOC present, it would seem that the TOC would be required to be restricted to the set of audio files that are being referenced… in that sense, the TOC would be bound to what’s there

Dave Cramer: that’s a restriction on the TOC, and i could see a TOC with appendices external to the publication’s bounds as we’re describing it here… forbidding that seems a bridge too far

Benjamin Young: bounds of publication only matter when we’re binding it, so it makes more sense in the context of web publications… what the UA would load or not load… the audiobooks corollary would maybe be packaging… a UA would gather all the pieces and bind it into some machinery… it needs to know what to put in the box
… with a web publication manifest, we’re learning things dynamically from HTML file, etc., whereas audiobooks are more static, a viewer viewing an audiobook who wants to sandbox it, is going to avoid anything not in the manifest…

Ivan Herman: trying to remember… the bounds, currently, are defined in publication manifest or audiobooks?

Benjamin Young: See Reference to bounds in audiobooks

Benjamin Young: and less-so in pub-manifest

Matt Garrish: the question seems to be about whether it needs to be a prominent statement, stated at all?

Ivan Herman: regardless of the contents, if we have it in pub manifest in the general contents, maybe we don’t include it in audiobooks because it’s built on pub manifest anyway
… I would be in favor of removing from audiobooks and making it a reference, but not defining something like this, which would be a recipe for problems
… in leaving it in pub manifest, it may serve as the basis for other things later, it may come up

Matt Garrish: it’s just a definition in pub manifest, and some sentences explaining bounds in the context of web publications, just explaining the concept

Brady Duga: it does seem like bounds have an implication outside of TOCs, in audiobooks, because supplemental materials could point at other things on the web… so understanding what bounds means would be useful

Dave Cramer: duga, you’re saying that supplemental content could link to some audio element, and the question would be in what context the UA would play that audio file?

Brady Duga: could be a link to anything, HTML, wikipedia…

Dave Cramer: if we’re making the distinction, we’re saying UA should treat some content differently from others… what different thing is supposed to happen if it’s in the bounds or not
… trying to find out what actionable information is there for the UA for us to put it as the first normative concept in the audiobooks spec

Benjamin Young: this pivots on whether we define binding… digitally saying what is in bounds, what to load or not load… i only have that list of resources and lock out anything outside of that, or not… it would depend on the code i wrote… so we could do it non-normatively, to give back story or explanation to explain what we mean

Ivan Herman: i don’t know how we would test it, but my explanation would be a negative explanation… a UA might ignore a resource that is not in its bounds… it MAY ignore that because, e.g., if it goes offline, that document should not be required as part of the user experience… it makes sense to me to know that, and the UA knows what to include in the package…
… we’re at a point where we’re not bound normatively to a package right now, but at least this gives you a way to ignore things

Deborah Kaplan: what we’re doing has changed a lot since the last time we had this conversation… we can include it without a plan to use it right now… it’s not so much “is this wiki page essential” but rather “is this font essential?” is it ok if they’re not available, are being blocked, etc.

Ivan Herman: +1 to dkaplan3

Deborah Kaplan: . if we have a google analytics script, is it ok if we can’t reach it? is the essential document not there? we were thinking about all the parts of a publication that are not essential to reading it…. some polyfills might be essential… some are just going to be things like fonts and CSS that we can function without… that seemed to be what we were talking about

Brady Duga: agree with dkaplan3, I think that’s why we did it… but i also agree with dauwhe and bigbluehat… we’ve essentially created a label, but it doesn’t tell me what i need to know if it should be part of the publication or not…

Dave Cramer: what duga said… if there was some action here… a UA finds out something isn’t in the bounds, what it should do… what action should result from it? just talking about audiobooks spec

Deborah Kaplan: here’s an action… if you make a test for accessing pages within the bounds, ask if everything within the bounds is something that can be reached by publication navigation?
… we can write an automated test where this matters, but we are not defining requirements for reading systems as part of this…
… i don’t think this would be a requirement, but it would be available for a reading system
… the reading system can decide… and that is a MAY, not a SHOULD or MUST
… for the reading system—can you test to see if everything in the bounds is reachable? yes, you can

Ivan Herman: we discuss bounds only in non-normative sections, we define a term and give a general statement about it… i don’t know what the status is in audiobooks, but i have the impression that we have a consensus to remove it from audiobooks spec

Matt Garrish: seems like this is where the discussion is going… it’s not of NO value, but we don’t need a section… don’t think it’s a critical part of the spec… do we remove it or do we try to rewrite it?

Ivan Herman: it
… it’s not a SHOULD/MUST part of the specification

Dave Cramer: To determine whether a resource is within the bounds of an Audiobook, user agents MUST compare the absolute URL of a resource to the absolute URLs of the resources obtained from the union. If the resource is identified in the enumeration, it is within the bounds of the Audiobook. All other resources are external to the Audiobook.

Ivan Herman: having that term as a required term in audiobooks? we should remove that.

Matt Garrish: ok with just removing the section about bounds, 2.1?

Brady Duga: that’s fine, but 2.1.3, referencing it in a normative section, will have to change… particularly if in pub manifest it’s not a normative term.

Ivan Herman: we can create an action for the editor to take a closer look

Brady Duga: in pub manifest, it’s not in a normative section

Matt Garrish: terminology is normative, no?

Ivan Herman: not sure
… what’s the proposal?

Matt Garrish: to remove section 2.1, make edits to 2.1.3 to fix the references to publication bounds

Proposed resolution: remove the concept of bounds (2.1.1.) from the audiobooks spec and edit 2.1.3 to fix the reference to publication bounds (Ivan Herman)

Ivan Herman: +1

Matt Garrish: +1

Deborah Kaplan: +0

Benjamin Young: +1

Geoff Jukes: +1

Mateus Teixeira: +1

Brady Duga: +1

Dave Cramer: +1

Resolution #4: remove the concept of bounds (2.1.1.) from the audiobooks spec and edit 2.1.3 to fix the reference to publication bounds

Ivan Herman: let’s create an action for wendyreid?

Matt Garrish: she’s on vacation, we may have to figure it out
… i think we can handle it without her

Ivan Herman: we cannot move towards CR until all the editing is done… and that one should be done as well
… we cannot do a final version until the editor is back
… even if we do the edit, we need an approval from her

2. path to CR

Matt Garrish: agreed
… that’s it for our issues…. next topic is path to CR.
… our accessibility reviews are done?

Avneesh Singh: yes

Matt Garrish: we’re waiting on PING, we have an issue open, just need to follow up
… we also have process here on the agenda, but is there anything we should discuss in particular?

Ivan Herman: See the data we have to fill

Ivan Herman: the major thing is, we need some work on implementation and testing strategy… the more information we have, the better
… in “changes” we do not have a previous document, so it is not that relevant… what i’m really worried about in terms of the transition call is the implementations section
… bigbluehat, if you can add more to that and the testing strategy, that would be great

Benjamin Young: just for audiobooks?

Ivan Herman: for audiobooks and pub manifest

Benjamin Young: this will get primarily into JSON conformance… not sure how to test things like user agents… console logs, will need human input… can’t really write text for that, but i’ll certainly provide explanation on tests run on authored documents, but not sure how to explain tests on user agents

Matt Garrish: looking at the pub manifest part of it is something we have to do
… i’ll see if i have any thoughts about what else we can put on this document

Ivan Herman: one other thing… looking at defining a vocabulary, check if it’s useful, necessary, etc., so we can agree that the terms used by publishing community in EPUB correspond to pub manifest

Matt Garrish: i’ve put together an experimental xslt with gregorio’s help… this is underway

Matt Garrish: See Epub/Manifest mapping

Ivan Herman: yes, but can we write a couple paragraphs on the wiki page to describe that?

Matt Garrish: yes, definitely
… we have two minutes left…

Ivan Herman: sa

Matt Garrish: let’s get everyone who can weigh in on and provide feedback on the transition document contribute… that would be great help

Ivan Herman: question for avneesh… is there a reference you can give me on where we document that we’ve gone through the discussion with WAI?
… i have a reference to what janina told us, which is great, but is there anything else?

Avneesh Singh: yes, i have the email I sent to start the review

Ivan Herman: that’s great
… and we’re done!

3. Resolutions