15:15:47 <RRSAgent> RRSAgent has joined #pwg
15:15:47 <RRSAgent> logging to https://www.w3.org/2019/10/21-pwg-irc
15:15:48 <ivan> rrsagent, set log public
15:15:48 <ivan> Meeting: Publishing Working Group Telco
15:15:48 <ivan> Chair: matt
15:15:48 <ivan> Date: 2019-10-21
15:15:48 <ivan> Agenda: https://lists.w3.org/Archives/Public/public-publ-wg/2019Oct/0021.html
15:15:48 <ivan> ivan has changed the topic to: Meeting Agenda 2019-10-21: https://lists.w3.org/Archives/Public/public-publ-wg/2019Oct/0021.html
15:15:49 <ivan> Regrets+ wendy, garth, luc, romain
15:21:13 <Rachel> Regrets+ Rachel
15:57:00 <kersc> kersc has joined #pwg
15:57:49 <kersc> present+ George
15:58:28 <mateus> mateus has joined #pwg
15:58:35 <mateus> present+
15:58:43 <mateus> scribe: mateus
15:59:17 <dkaplan3> dkaplan3 has joined #pwg
16:00:06 <ivan> present+
16:00:09 <dkaplan3> present+
16:00:17 <mattg> present+
16:00:34 <ivan> present+ george
16:00:41 <Avneesh> Avneesh has joined #pwg
16:01:23 <Teenya> Teenya has joined #pwg
16:01:25 <geoffjukes> geoffjukes has joined #pwg
16:01:35 <Teenya> present+
16:01:53 <dauwhe> present+
16:02:19 <rkwright> rkwright has joined #pwg
16:02:55 <mattg> https://www.w3.org/publishing/groups/publ-wg/Meetings/Minutes/2019/2019-10-14-pwg
16:02:56 <mateus> mattg: first step, approve minutes...
16:03:08 <mateus> ... minutes approved
16:03:09 <rkwright> present+
16:03:13 <ivan> resolved: last week's meeting approved
16:03:28 <Avneesh> present+
16:03:35 <mattg> https://github.com/w3c/pub-manifest/issues/115
16:03:58 <ivan> regrets+ nellie
16:04:04 <mateus> ... 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
16:04:19 <ivan> Topic: single localizable string
16:04:20 <franco> franco has joined #pwg
16:04:22 <franco> present+
16:04:53 <JuanCorona> JuanCorona has joined #pwg
16:04:53 <dkaplan3> q+
16:05:05 <JuanCorona> present+
16:05:06 <mateus> ... a question of two properties... removing requirement for single values, allowing multiple languages in an array
16:05:11 <marisa> marisa has joined #pwg
16:05:14 <mattg> q- dkaplan
16:05:16 <mateus> dkaplan3: the solution to make it an array makes perfect sense
16:05:27 <david_stroup> david_stroup has joined #pwg
16:05:38 <BenSchroeter> BenSchroeter has joined #pwg
16:05:40 <BenSchroeter> present+
16:05:41 <mateus> mattg: the use of localizable strings works with schema.org, provides for multiple languages
16:05:55 <mateus> ivan: correct, these have several values out of the box in schema.org... we don't have to do anything
16:06:14 <mateus> mattg: it's not something that in EPUB we've gone into doing (multiple language a11y summaries, for example)
16:06:14 <marisa> present+
16:06:28 <david_stroup> present+
16:06:29 <mateus> ... we're not breaking anything or deviating
16:06:50 <mateus> ... seems like we can resolve this
16:06:50 <CharlesL> CharlesL has joined #pwg
16:06:54 <CharlesL> present+
16:07:18 <ivan> Proposed: the accessibilitySummary and description properties accept arrays of strings
16:07:20 <geoffjukes> present+
16:07:21 <dkaplan3> +1
16:07:21 <ivan> +1
16:07:22 <bigbluehat> present+
16:07:23 <geoffjukes> +1
16:07:24 <mattg> +1
16:07:24 <mateus> +1
16:07:25 <George> +1
16:07:29 <marisa> +1
16:07:29 <Avneesh> +1
16:07:30 <dauwhe> +.9
16:07:47 <BenSchroeter> +1
16:07:48 <rkwright> +1
16:08:08 <mateus> dauwhe: i wonder about implicitly endorsing a design choice that every given language of a work should be in the same publication
16:08:17 <Bill_Kasdorf> Bill_Kasdorf has joined #pwg
16:08:23 <Bill_Kasdorf> present+
16:08:28 <mateus> mattg: but i don't think we should exclude this from the possibilities
16:08:31 <david_stroup> +1
16:08:33 <mateus> ... if you need it, it's there
16:08:36 <mateus> dauwhe: yep, that's fine
16:08:41 <ivan> resolved: the accessibilitySummary and description properties accept arrays of strings
16:09:02 <mattg> https://github.com/w3c/pub-manifest/issues/112
16:09:12 <ivan> Topic: Presence of `id` should be a SHOULD? #112
16:09:29 <mateus> 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
16:09:50 <duga> duga has joined #pwg
16:10:20 <mateus> ... should we continue to recommend the presence of `id` and `type`? they are not strictly necessary... do you agree, disagree?
16:10:23 <mattg> q?
16:10:31 <duga> present+
16:10:34 <dauwhe> q+
16:10:43 <mattg> q- dauwhe
16:11:04 <mateus> dauwhe: some concerns about increasing authoring burden in order to satisfy requirements of RFD processing...
16:11:07 <bigbluehat> q+
16:11:17 <mateus> ... "i make the webpage, don't have to come up with an id"
16:11:22 <ivan> q+
16:11:34 <mateus> mattg: yes, and certainly why they're not required... alternatively, we could put it into best practices
16:11:43 <mateus> ... explain why it's useful to have them
16:11:43 <g_pellegrino> g_pellegrino has joined #pwg
16:11:48 <g_pellegrino> present+
16:11:56 <mattg> q?
16:12:12 <mattg> q- bigbluehat
16:13:08 <mattg> q- ivan
16:13:08 <mateus> 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
16:13:37 <bigbluehat> q+
16:13:44 <mateus> ivan: two things—on `type`, schema.org processors are dependent on the type of the JSON contents as a whole...
16:14:23 <mateus> ... when I use the testing tool they offer, the absence results in a bunch of errors...
16:15:11 <mateus> ... 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...
16:15:26 <mateus> ... that's when I realized that there is nothing that identified the resource as a whole thing
16:15:29 <mattg> q- bigbluehat
16:15:58 <mateus> bigbluehat: related to what ivan said... schema.org with its type injection.... would seem to keep it in the recommended space
16:16:26 <mateus> ... 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
16:16:37 <mateus> ... this would also happen with publication manifest inside a web page
16:17:33 <mateus> ... 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...
16:17:54 <mateus> mattg: there's precedent in EPUB for unique identifier for a publication...  i don't think this would add any burden either way
16:18:14 <mattg> q?
16:18:21 <mateus> ... 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
16:18:29 <mateus> ... should we put this to a vote?
16:18:36 <mateus> anyone who can't live with it?
16:18:38 <ivan> Proposed: `id` and `type` are RECOMMENDED properties
16:18:46 <mattg> +1
16:18:49 <geoffjukes> +1
16:18:51 <ivan> +1
16:18:52 <mateus> +1
16:18:54 <bigbluehat> +1
16:18:55 <Bill_Kasdorf> +1
16:18:56 <rkwright> +1
16:18:59 <david_stroup> +1
16:19:03 <BenSchroeter> +1
16:19:10 <ivan> Resolved: `id` and `type` are RECOMMENDED properties
16:19:25 <mateus> mattg: we'll make them RECOMMENDED properties, then
16:19:31 <mattg> https://github.com/w3c/audiobooks/issues/26
16:19:45 <mateus> ... next issue, 26, from audiobooks repository, opened by dauwhe
16:19:59 <dauwhe> q+
16:20:00 <ivan> Topic: bounds of an audiobook #26
16:20:54 <mateus> .... 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?
16:21:22 <mateus> 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?
16:21:51 <Karen> Karen has joined #pwg
16:22:17 <mateus> ... 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
16:22:26 <mattg> q?
16:22:29 <dauwhe> ack dauw
16:22:30 <mattg> q- dauwhe
16:22:31 <mateus> ... i'm not sure we need the whole section about bounds that we then don't do anything with
16:22:32 <George> q+
16:22:47 <bigbluehat> q+
16:23:09 <mateus> mattg: i agree... bounds lose some of the interest when talking about packages, for example
16:23:22 <mateus> ... regardless of how interesting it is, a publication still have some bounds to it...
16:24:00 <mateus> 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?
16:24:02 <mattg> q- george
16:24:06 <mateus> mattg: maybe the prominence is misplaced
16:24:40 <mateus> 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
16:25:15 <mateus> 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
16:25:16 <mattg> q- bigbluehat
16:25:58 <ivan> q+
16:26:12 <dauwhe> q+
16:26:16 <mateus> 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
16:26:40 <duga> q+
16:27:00 <mateus> ... 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...
16:27:08 <mattg> q- ivan
16:27:33 <bigbluehat> https://w3c.github.io/audiobooks/#audio-bounds
16:27:37 <mateus> ivan: trying to remember... the bounds, currently, are defined in publication manifest or audiobooks?
16:27:43 <dauwhe> https://w3c.github.io/audiobooks/#audio-bounds
16:28:11 <dauwhe> q?
16:28:12 <bigbluehat> and less-so in pub-manifest https://w3c.github.io/pub-manifest/#dfn-bounds
16:28:20 <mateus> mattg: the question seems to be about whether it needs to be a prominent statement, stated at all?
16:28:53 <mateus> 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
16:29:10 <dauwhe> q- because brady is much smarter
16:29:13 <dauwhe> q?
16:29:17 <mateus> ... 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
16:29:23 <dauwhe> q-
16:30:06 <mateus> ... in leaving it in pub manifest, it may serve as the basis for other things later, it may come up
16:30:29 <mateus> mattg: it's just a definition in pub manifest, and some sentences explaining bounds in the context of web publications, just explaining the concept
16:31:00 <dauwhe> q+
16:31:00 <mattg> q- duga
16:31:02 <bigbluehat> q+ to suggest we describing "binding" in addition to "bounds"
16:31:09 <mateus> 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
16:31:30 <mattg> q- dauwhe
16:31:36 <mateus> 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?
16:31:45 <mateus> duga: could be a link to anything, HTML, wikipedia...
16:31:47 <ivan> q+
16:32:12 <dkaplan3> q+
16:32:17 <mateus> 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
16:32:42 <mattg> q- bigbluehat
16:32:43 <mateus> ... 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
16:34:00 <duga> q+
16:34:07 <mattg> q- ivan
16:34:09 <mateus> 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
16:35:03 <mateus> 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...
16:35:25 <mattg> q- dkaplan
16:35:26 <mateus> ... 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
16:36:31 <mateus> 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.
16:36:52 <ivan> +1 to dkaplan3
16:37:27 <mattg> q- duga
16:37:29 <mateus> .... 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
16:38:14 <dauwhe> q+
16:38:36 <mateus> 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...
16:38:37 <dkaplan3> q+
16:39:07 <mattg> q- dauwhe
16:39:08 <dauwhe> ack dauwhe
16:39:11 <mateus> 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
16:39:43 <ivan> q+
16:39:46 <duga> q+
16:39:47 <ivan> ack dkaplan3
16:39:50 <mateus> 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?
16:39:54 <ivan> ack dkaplan
16:40:08 <mateus> ... we can write an automated test where this matters, but we are not defining requirements for reading systems as part of this...
16:40:22 <mateus> ... i don't think this would be a requirement, but it would be available for a reading system
16:40:35 <mateus> ... the reading system can decide... and that is a MAY, not a SHOULD or MUST
16:40:51 <mattg> ack ivan
16:40:57 <mateus> ... for the reading system—can you test to see if everything in the bounds is reachable? yes, you can
16:41:27 <duga> q-
16:42:06 <mateus> 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
16:42:44 <mateus> 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?
16:42:46 <duga> q+
16:42:47 <mateus> ivan: it
16:43:07 <mateus> ... it's not a SHOULD/MUST part of the specification
16:43:12 <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.
16:43:39 <mateus> ivan: having that term as a required term in audiobooks? we should remove that.
16:43:51 <mateus> mattg: ok with just removing the section about bounds, 2.1?
16:43:55 <mattg> ack duga
16:44:21 <mateus> 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.
16:44:38 <mateus> ivan: we can create an action for the editor, who is not present, to take a closer look
16:44:55 <mateus> duga: in pub manifest, it's not in a normative section
16:45:04 <mateus> mattg: terminology is normative, no?
16:45:07 <mateus> ivan: not sure
16:45:14 <mateus> ... what's the proposal?
16:45:35 <mateus> mattg: to remove section 2.1, make edits to 2.1.3 to fix the references to publication bounds
16:45:42 <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
16:45:57 <ivan> +1
16:45:58 <mattg> +1
16:46:06 <dkaplan3> +0
16:46:16 <bigbluehat> +1
16:46:25 <geoffjukes> +1
16:46:35 <mateus> +1
16:46:42 <duga> +1
16:46:52 <dauwhe> +1
16:46:56 <ivan> Resolved: remove the concept of bounds (2.1.1.) from the audiobooks spec and edit 2.1.3 to fix the reference to publication bounds
16:47:14 <mateus> ivan: let's create an action for wendyreid?
16:47:30 <mateus> mattg: she's on vacation, we may have to figure it out
16:47:46 <mateus> ... i think we can handle it without her
16:48:20 <mateus> ivan: we cannot move towards CR until all the editing is done... and that one should be done as well
16:48:27 <mateus> ... we cannot do a final version until the editor is back
16:48:39 <mateus> ... even if we do the edit, we need an approval from her
16:48:43 <mateus> mattg: agreed
16:49:04 <ivan> Topic: path to CR
16:49:11 <mateus> ... that's it for our issues.... next topic is path to CR.
16:49:30 <mateus> ... our accessibility reviews are done?
16:49:33 <mateus> avneesh: yes
16:49:49 <mateus> mattg: we're waiting on PING, we have an issue open, just need to follow up
16:49:53 <mateus> q+
16:49:55 <ivan> q+
16:50:19 <ivan> -> https://github.com/w3c/publ-wg/wiki/%5BPublishing-WG%5D-CR-Transition-for-pub-manifest-and-audiobooks the data we have to fill
16:50:21 <mateus> ... we also have process here on the agenda, but is there anything we should discuss in particular?
16:50:25 <mateus> q-
16:52:10 <mateus> ivan: the major thing is, we need some work on implementation and testing strategy... the more information we have, the better
16:53:14 <mateus> ... 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
16:53:21 <bigbluehat> q+
16:53:28 <mattg> ack ivan
16:53:35 <mateus> ... bigbluehat, if you can add more to that and the testing strategy, that would be great
16:53:41 <mateus> bigbluehat: just for audiobooks?
16:53:43 <mattg> ack bigbluehat
16:54:06 <mateus> ivan: for audiobooks and pub manifest
16:55:46 <mateus> 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
16:56:19 <mateus> mattg: looking at the pub manifest part of it is something we have to do
16:56:37 <mateus> ... i'll see if i have any thoughts about what else we can put on this document
16:57:27 <mattg> https://github.com/w3c/pub-manifest/wiki/Publication-Manifest-to-EPUB-Mapping
16:57:45 <mateus> 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
16:58:19 <mateus> mattg: i've put together an experimental xslt with gregorio's help... this is underway
16:58:35 <mateus> ivan: yes, but can we write a couple paragraphs on the wiki page to describe that?
16:58:40 <mateus> mattg: yes, definitely
16:58:48 <mateus> ... we have two minutes left...
16:59:13 <ivan> q+
16:59:17 <ivan> sa
16:59:18 <mateus> ... let's get everyone who can weigh in on and provide feedback on the transition document contribute... that would be great help
16:59:22 <ivan> ack Avneesh
16:59:42 <mateus> 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?
17:00:20 <mateus> ... i have a reference to what janina told us, which is great, but is there anything else?
17:00:28 <mateus> avneesh: yes, i have the email i sent to start the review
17:00:31 <mateus> ivan: that's great
17:00:53 <dkaplan3> dkaplan3 has left #pwg
17:00:59 <CharlesL> CharlesL has left #pwg
17:01:11 <mateus> ... and we're done!
17:01:12 <ivan> rrsagent, draft minutes
17:01:12 <RRSAgent> I have made the request to generate https://www.w3.org/2019/10/21-pwg-minutes.html ivan
17:01:12 <ivan> zakim, bye
17:01:12 <ivan> rrsagent, bye
17:01:12 <RRSAgent> I see no action items
17:01:12 <Zakim> leaving.  As of this point the attendees have been George, mateus, ivan, dkaplan, mattg, Teenya, dauwhe, rkwright, Avneesh, franco, JuanCorona, BenSchroeter, marisa, david_stroup,
17:01:12 <Zakim> Zakim has left #pwg