<scribe> scribe: mateus

<mattg> https://www.w3.org/publishing/groups/publ-wg/Meetings/Minutes/2019/2019-10-14-pwg

mattg: first step, approve minutes...
... minutes approved

RESOLUTION: last week's meeting approved

<mattg> https://github.com/w3c/pub-manifest/issues/115

mattg: 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

single localizable string

mattg: a question of two properties... removing requirement for single values, allowing multiple languages in an array

dkaplan3: the solution to make it an array makes perfect sense

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

ivan: correct, these have several values out of the box in schema.org... we don't have to do anything

mattg: 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

<ivan> Proposed: the accessibilitySummary and description properties accept arrays of strings

<dkaplan3> +1

<ivan> +1

<geoffjukes> +1

<mattg> +1

+1

<George> +1

<marisa> +1

<Avneesh> +1

<dauwhe> +.9

<BenSchroeter> +1

<rkwright> +1

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

mattg: but i don't think we should exclude this from the possibilities

<david_stroup> +1

mattg: if you need it, it's there

dauwhe: yep, that's fine

RESOLUTION: the accessibilitySummary and description properties accept arrays of strings

<mattg> https://github.com/w3c/pub-manifest/issues/112

Presence of `id` should be a SHOULD? #112

mattg: 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?

dauwhe: 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"

mattg: yes, and certainly why they're not required... alternatively, we could put it into best practices
... explain why it's useful to have them

bigbluehat: 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: 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

bigbluehat: 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 `id`s 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...

mattg: 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?

anyone who can't live with it?

<ivan> Proposed: `id` and `type` are RECOMMENDED properties

<mattg> +1

<geoffjukes> +1

<ivan> +1

+1

<bigbluehat> +1

<Bill_Kasdorf> +1

<rkwright> +1

<david_stroup> +1

<BenSchroeter> +1

RESOLUTION: `id` and `type` are RECOMMENDED properties

mattg: we'll make them RECOMMENDED properties, then

<mattg> https://github.com/w3c/audiobooks/issues/26

mattg: next issue, 26, from audiobooks repository, opened by dauwhe

bounds of an audiobook #26

mattg: 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?

dauwhe: 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

mattg: 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...

dauwhe: 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?

mattg: maybe the prominence is misplaced

George: 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

dauwhe: 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

bigbluehat: 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...

<bigbluehat> https://w3c.github.io/audiobooks/#audio-bounds

ivan: trying to remember... the bounds, currently, are defined in publication manifest or audiobooks?

<dauwhe> https://w3c.github.io/audiobooks/#audio-bounds

<bigbluehat> and less-so in pub-manifest https://w3c.github.io/pub-manifest/#dfn-bounds

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

ivan: 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

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

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

dauwhe: 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?

duga: could be a link to anything, HTML, wikipedia...

dauwhe: 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

bigbluehat: 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: 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

dkaplan3: 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> +1 to dkaplan3

dkaplan3: 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

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...

dauwhe: 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

dkaplan3: 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: 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

mattg: 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: it
... it's not a SHOULD/MUST part of the specification

<dauwhe> > 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: having that term as a required term in audiobooks? we should remove that.

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

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: we can create an action for the editor, who is not present, to take a closer look

duga: in pub manifest, it's not in a normative section

mattg: terminology is normative, no?

ivan: not sure
... what's the proposal?

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

<ivan> Proposed: 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> +1

<mattg> +1

<dkaplan3> +0

<bigbluehat> +1

<geoffjukes> +1

+1

<duga> +1

<dauwhe> +1

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: let's create an action for wendyreid?

mattg: she's on vacation, we may have to figure it out
... i think we can handle it without her

ivan: 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

mattg: agreed

path to CR

mattg: that's it for our issues.... next topic is path to CR.
... our accessibility reviews are done?

avneesh: yes

mattg: we're waiting on PING, we have an issue open, just need to follow up

<ivan> the data we have to fill

mattg: we also have process here on the agenda, but is there anything we should discuss in particular?

ivan: the major thing is, we need some work on implementation and testing strategy... the more information we have, the better
... in "changes", one thing we can mention is JSON-LD... 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

bigbluehat: just for audiobooks?

ivan: for audiobooks and pub manifest

bigbluehat: 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

mattg: 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

<mattg> https://github.com/w3c/pub-manifest/wiki/Publication-Manifest-to-EPUB-Mapping

ivan: 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

mattg: i've put together an experimental xslt with gregorio's help... this is underway

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

mattg: yes, definitely
... we have two minutes left...

<ivan> sa

mattg: let's get everyone who can weigh in on and provide feedback on the transition document contribute... that would be great help

ivan: 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: yes, i have the email i sent to start the review

ivan: that's great
... and we're done!

This is scribe.perl Revision: 1.154  of Date: 2018/09/25 16:35:56  
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: Irssi_ISO8601_Log_Text_Format (score 1.00)

Present: George mateus ivan dkaplan3 mattg Teenya dauwhe rkwright Avneesh franco JuanCorona BenSchroeter marisa david_stroup CharlesL geoffjukes bigbluehat Bill_Kasdorf duga g_pellegrino
Regrets: wendy garth luc romain Rachel nellie
Found Scribe: mateus
Inferring ScribeNick: mateus
Agenda: https://lists.w3.org/Archives/Public/public-publ-wg/2019Oct/0021.html
WARNING: Could not parse date.  Unknown month name "10": 2019-10-21
Format should be like "Date: 31 Jan 2004"

WARNING: No date found!  Assuming today.  (Hint: Specify
the W3C IRC log URL, and the date will be determined from that.)
Or specify the date like this:
<dbooth> Date: 12 Sep 2002

People with action items: 

WARNING: IRC log location not specified!  (You can ignore this 
warning if you do not want the generated minutes to contain 
a link to the original IRC log.)