16:38:20 RRSAgent has joined #pwg 16:38:20 logging to https://www.w3.org/2019/11/04-pwg-irc 16:38:21 rrsagent, set log public 16:38:21 Meeting: Publishing Working Group Telco 16:38:21 Chair: garth 16:38:21 Date: 2019-11-04 16:38:21 Agenda: https://lists.w3.org/Archives/Public/public-publ-wg/2019Oct/0030.html 16:38:21 ivan has changed the topic to: Meeting Agenda 2019-11-04: https://lists.w3.org/Archives/Public/public-publ-wg/2019Oct/0030.html 16:38:22 Regrets+ luc 16:51:25 mattg has joined #pwg 16:56:11 present+ 16:59:20 present+ 16:59:31 George has joined #pwg 16:59:40 present+ George 17:00:14 present+ 17:00:16 scribe: mateus 17:00:24 present+ 17:00:30 present+ 17:00:40 Avneesh has joined #pwg 17:01:01 dkaplan3 has joined #pwg 17:01:15 present+ 17:01:17 present+ 17:01:55 BenSchroeter has joined #pwg 17:02:04 present+ 17:02:56 garth has joined #pwg 17:03:07 present+ Garth 17:03:18 romain has joined #pwg 17:03:24 marisa has joined #pwg 17:03:38 present+ 17:03:45 present+ 17:03:46 present+Please mute yourself if you are not speaking 17:04:04 franco has joined #pwg 17:04:20 https://www.w3.org/publishing/groups/publ-wg/Meetings/Minutes/2019/2019-10-21-pwg 17:04:46 josh has joined #pwg 17:04:51 garth: first, approving minutes... any corrections or objections? 17:04:53 resolved: last week's minutes accepted 17:04:55 present+ 17:04:59 ... minutes approved 17:05:07 present+ 17:05:10 Nellie has joined #pwg 17:05:21 present+ 17:05:35 ... first on the agenda, review changes to pub manifest (issue 138, PR 131) 17:05:45 present+ 17:05:48 [5] https://github.com/w3c/pub-manifest/issues/138 17:05:49 [6] https://github.com/w3c/pub-manifest/pull/131 17:05:49 present+ 17:05:49 CharlesL has joined #pwg 17:05:56 present+ 17:06:02 Topic: last manifest PR-s 17:06:02 mattg: a number of issues came up last week... dauwhe had raised a couple of questions... going through algo to implement the spec 17:06:15 present+ 17:06:26 ... the major ones in 138 are that we're not going to have a MUST NOT on fragment ids on manifest level, but could be restricted at the profile level 17:06:55 duga has joined #pwg 17:06:58 ... the other one (PR 131) deals with publication of resources in reading order and resource list 17:07:13 ... we had "MUST NOT" but we will leave it at "SHOULD NOT"... if it's there, we won't mess around with your reading order 17:07:34 ... strongly advised that you don't declare resources multiple times in reading order... leads to ambiguity 17:07:41 ... we want to generally avoid that issue 17:07:46 present+ 17:07:52 ... other than that, the changes were mostly editorial cleanup 17:07:56 q? 17:08:14 ... to recap: fragment ids are allowed, and you can declare multiple resources, and it will be a warning (still) 17:08:47 ... we can discuss the resource issues now... i don't think we need to restrict fragment ids at the publication level 17:08:51 q? 17:09:05 garth: nobody on the queue... ivan made an off comment on alternate issues... what did you mean? 17:09:41 ivan: we also had an issue in the last few days on what happens if you provide an alternate [?] 17:09:53 mattg: choosing alternates is issue 133... separate from 138 17:10:02 garth: let's stick with 138 for the moment 17:10:20 q+ 17:10:23 q? 17:10:25 q- 17:10:31 garth_ has joined #pwg 17:10:34 q? 17:10:38 q? 17:10:38 q? 17:10:38 q? 17:10:40 George_ has joined #pwg 17:10:58 garth: nobody on the queue... dauwhe, you had chimed in on this issue. are you happy with where we are? 17:11:14 Karen_ has joined #pwg 17:11:36 dauwhe: yes, i think allowing fragment ids is important, but i'm fine with the decision on duplicate resources... when we make restrictions i want us to be very conscious about what we're restricting and why 17:11:51 https://github.com/w3c/pub-manifest/issues/133 17:11:58 garth: ok, let's consider that folks are happy with 138... mattg, want to cover 133? 17:12:08 Topic: choosing alternatives 17:13:15 mattg: this is about what to make about alternate resources... saying they have to be unique on one property and the UA can make the choice... but we don't talk about what the unique properties are, how the UA goes about picking them... essentially, it's two questions: we have encoding format, but no properties for selecting alternatives? what do we need here? ... what are we selecting from and what is the process for selecting them? 17:13:35 q? 17:14:05 Bill_Kasdorf has joined #pwg 17:14:13 present+ 17:14:14 q+ 17:14:20 ... should figure this out before going to CR... unfortunately, i don't know what the best resolution is... seems like a case for media queries, but it might be too deep in the weeds... for selecting them, my general thought is we follow HTML--the UA picks the one it can handle, and if it can't, you get an error message... without going resource to resource one by one 17:14:30 ... those are the questions 17:14:34 q+ 17:14:34 ack dauwhe 17:15:02 dauwhe: using this as a general purpose mechanism makes me a little nervous... reminds me of multiple renditions in EPUB... and how to present a bunch of complex choices to users... 17:15:05 +1 to dauwhe 17:15:22 q+ 17:15:35 +1 dauwhe 17:15:38 ... this seems like an entirely good thing to point to media overlays, which sort of augment rather than replace the underlying content, but defining a mechanism to provide an entirely different primary content experience seems like a world of complexity 17:15:39 +1 17:15:46 garth: you had me at multiple renditions 17:15:48 ack marisa 17:16:19 marisa: originally, with alternate, we didn't think about offering more than one... then with audiobooks it came up that you can have a pure HTML alternate or synched text alternate... 17:16:25 q+ 17:17:06 ... there's sort of an edge case here, which is if you have two alternates... like deep voice or high pitched voice... and you want a consistent experience, so the selection should be the default... and the encoded format wouldn't work in this case because it would be the same for either option 17:17:07 rkwright has joined #pwg 17:18:02 ... the other thing was for it to be consistent with the way we write about URLs, to be consistent with the rest of our data values... i don't know what we should choose... but i'm wary about inventing a selection mechanism... HTML-style audio fallback wouldn't really work here either... seems like a very complicated issue 17:18:02 ack ivan 17:18:36 ivan: to add to the complication, we have to remind ourselves that the alternate originally appeared for audiobooks, and we decided other types of publication might use it, so we pushed it to pub manifest 17:18:57 ... so any mechanism defined here would be an absolute nightmare... so it should be strictly profile-specific, because otherwise there is no end to it 17:19:01 q? 17:19:40 garth: continuing from ivan... avoiding the nightmare seems like a good thing... is making it profile-specific a way to get around it for now? 17:20:46 ivan: yes, but we will need to say something about audiobooks... the nightmare is more manageable in the general case, but we still need to define it... also depends on the kind of resource... audio is one thing, but also cover page alternates (images), which would possibly be a different kind of mechanism... like picking based on resolution 17:20:59 q+ 17:21:06 ... so not only dependent on profile, but also the role of the resource for which the alternate is defined... it's a multiple-dimension thing 17:21:31 ack mattg 17:21:54 q+ 17:22:05 mattg: this is sort of what my question is... does it belong in pub manifest or can it be defined for synched media? if that's the primary use case, wouldn't it be better to define it in that spec? 17:22:13 ack Avneesh 17:22:28 +1 to Avneesh 17:22:34 Avneesh: i think that we should keep it as simple as possible, not get into a situation where we get into a nasty loop to define more and more things 17:22:35 +1 17:22:55 ... we should keep the audiobook case simple 17:22:58 +10000 to Avneesh 17:23:04 garth: so should we keep it only relevant to synched media? 17:23:19 q? 17:23:20 Avneesh: yes, and keep it specific to audio 17:23:49 ack marisa 17:23:57 q+ 17:23:59 q+ 17:24:35 marisa: i don't mind extending synched media to incorporate this, but i'm afraid it would be a very narrow solution, because as Avneesh said, you can have both HTML and audio, and it might get awkward on making that call... would rather not do anything... if there are so many books that can't be disambiguated, then we realize that the standard has to accommodate more, but it doesn't seem that pressing 17:25:23 q? 17:25:27 ack mattg 17:25:27 q+ 17:25:30 mattg: i misunderstood, didn't know there was an audiobook case here too... one thing we can do with it is say that alternate only provides different encoding formats, and leave it open to profiles to do more interesting things, and that's it... it's sort of open-ended at the moment what you're supposed to make with it... the uses are not very well defined 17:25:37 ack ivan 17:25:53 q- 17:26:14 ivan: we can make what Avneesh proposed to say that this version of this spec does not define anything, put it in a note in the document... and make it clear that future versions of the specs may come up with a more complex mechanism if there's a need for it 17:26:33 q? 17:26:39 ... inventing things for use cases we don't know about is not a good idea, but we know that this may require at some point a more complex mechanism, so we can make this note that we wait for use cases to come up 17:26:52 garth: mattg, are you comfortable with that direction? 17:27:05 q? 17:27:08 mattg: yes, just saying that we're not defining anything at this point in time, and leave it to future versions and profiles 17:27:14 garth: is that acceptable? 17:27:33 q? 17:27:43 marisa: yes, it's ok. there is one accessibility use case about switching voices, but we need to do more research about it, and future versions of the spec could introduce a solution to that 17:27:50 garth: nobody on the queue.... sounds like consensus 17:28:04 ... anything else that comes to mind that would fall into recent substantive changes? 17:28:05 q? 17:28:06 https://github.com/w3c/pub-manifest/issues/141 17:28:08 mattg: yeah, there's more 17:28:22 ... 141, one ivan raised over the weekend, whether or not we have to resolve prefixes 17:28:23 NO 17:28:25 Topic: resolving prefixes in the manifest 17:28:30 ivan: the answer is no 17:28:31 g_pellegrino has joined #pwg 17:28:34 NO 17:28:36 present+ 17:29:41 q? 17:29:42 mattg: right, the answer is no, but just seeing if everyone is on board with it... we had made it a requirement in EPUB that they be resolved, and we learned it was not the best approach... it's useful and certainly if you want json-ld processing it's something you need, but let's not get into validating and resolving them in our processing algorithm... let's focus on the more useful part, creating some useful prefixes that people can use, and nothing 17:29:42 else 17:29:53 garth: seems like consensus... anyone else want to chime in? 17:29:58 q+ 17:30:06 ack ivan 17:30:08 ... i think "no" is where we are 17:30:50 ivan: right. what is our next step with this? regarding predefined prefixes... knowing schema.org already predefines a number of prefixes... like dc and foaf, biblio... all predefined in schema.org 17:30:57 q? 17:31:03 ... do we want to add predefined prefixes in our own context? 17:31:27 q+ 17:31:29 ... mattg and i were looking and some predefined ones in EPUB... maybe onix and [???] would be useful? 17:31:40 s/???/MARC/ 17:31:40 s/???/marc/ 17:32:05 https://www.loc.gov/marc/ 17:32:15 david_stroup has joined #pwg 17:32:17 ... that's the only question, and we don't need final list for CR because it doesn't change the technical content of the final document in any way 17:32:20 ack Bill_Kasdorf 17:32:56 Bill_Kasdorf: i would advocate for keeping it informal for the extent of treating onix and marc as examples... particularly because we want it to be relevant for all kinds of publications, but we don't want to single anything out. 17:33:16 q+ 17:33:41 ivan: the question is, which are the ones that are particularly and largely in use? just to make the life of the user easier... there are three or four that from the outside may be useful, and it doesn't cost anything to add them to the context 17:33:52 Bill_Kasdorf: what's the UA supposed to do with that 17:34:27 ivan: for internal representation, we don't do anything with those... the question is, e.g., is there a reason for putting data into the manifest that is onix data? 17:34:31 q? 17:34:36 ack dkaplan3 17:34:43 ack dkaplan 17:35:26 q? 17:35:37 dkaplan3: agreeing with what Bill_Kasdorf says... there are a lot of prefixes that will be useful in specific contexts... there are gonna be field-specific prefixes in publishing, libraries, etc... and they won't be there to be useful for the UA... they're there because they identify the specific information/metadata... and the UA will probably have its own ways to handle them, but i don't think we are going to be expecting that 17:35:44 q+ 17:35:57 ... makes a lot of sense to point out specific ones that will be used a lot, but it makes less sense to make an exclusive list 17:36:02 q+ 17:36:09 ... i am more in the example camp than in the specificity camp 17:36:13 ack mattg 17:36:45 MeSH, btw https://www.nlm.nih.gov/mesh/meshhome.html 17:36:46 q+ 17:36:59 ack bigbluehat 17:37:05 mattg: there's an argument here... if we're expecting profiles for specific use cases, we should maybe wait until specific prefixes are needed... but the context document is easy to update... i don't think it's harmful... but let's not just add things for the sake of having a list 17:37:28 https://w3c.github.io/pub-manifest/#extensibility-manifest-properties 17:38:31 bigbluehat: agreed with mattg... this really should be part of the profile... the key practical scenario is that whatever we don't add in the context in the profile will be added to the context of the individual publications... so we need to acknowledge that, and publishers should know. there is danger, though, that any prefix you pick and assign a URL could be changed, you kind of want to version this and put it through a publishing oversight... 17:38:50 q+ 17:38:58 ... to make sure you're not moving things... a community using them can suffer when moving those things underneath 17:39:11 ... when we publish a new context, it really needs a new identifier 17:39:30 ack Bill_Kasdorf 17:40:06 Bill_Kasdorf: the reason i'm strongly in the example camp is that it shows what to do with those things... we don't want to discourage use of prefixes just because they haven't been defined... we should be agnostic 17:40:13 ack ivan 17:40:37 q+ 17:41:12 ivan: i have no problem with anything that was said... the only thing i am asking here that i don't have the answer for... EPUB does have these four or five prefixes defined, some very IDPF-specific... is there an expectation in the community that those continue to be there because they were there in EPUB? maybe we can include them just to avoid problems 17:41:20 ack dkaplan 17:41:23 q+ 17:42:07 dkaplan: another concern with defining specific prefix vocabularies... it runs the risk of being culturally and nationally chauvinist... in the way we're fairly bad about in standards in general... like marc being very US-specific, being anglophone, american or western-european... 17:42:13 +1 to deborah (maybe it should be +10000, because this is what I seem to use:-) 17:42:18 +1 17:42:23 +1 to Deborah 17:42:31 Ben: you can use any prefix -- this way https://w3c.github.io/pub-manifest/#extensibility-manifest-properties 17:42:34 ... we are saying in the standard by putting it in the list that we think These Are Important 17:42:58 mattg: to the question about whether onix or marc are necessary... i'd have to research EPUB for that, but my gut feeling is "no" 17:43:28 ... it was very EPUB-y and strange... i would say "no"... i don't think the mechanisms they were used for would be useful for web publications 17:43:31 q? 17:43:37 ack mattg 17:43:38 ivan: we can propose to close the issue without further action 17:43:55 +1 17:43:57 +1 17:43:59 garth: lots of +1s... is that i? 17:44:00 +1 17:44:01 +1 17:44:02 +1 17:44:04 +1 17:44:09 +1 17:44:10 s/i?/it? 17:44:15 +1 17:44:18 ... anything else? 17:44:19 https://github.com/w3c/pub-manifest/issues/145 17:44:20 s/Ben:/bigbluehat: 17:44:32 Topic: cover description always recommended? 17:44:38 mattg: yes, 145... i think this is coming to a solution... that we recommend both a name and a description for an image... 17:44:52 ... like saying we need alt text and description for all images, which is not always true... 17:45:00 q+ 17:45:11 https://github.com/w3c/pub-manifest/issues/145#issuecomment-549448461 17:45:19 ... recommend we point to WCAG... would be ideal if we could agree on this now, or wrap it up in the next couple of days 17:45:40 ... not all covers are meaningful and need to be described or need extended descriptions... 17:45:47 q? 17:45:48 ... this becomes more of a guidance to the user and the author 17:46:04 ack dkaplan 17:46:43 dkaplan: flashing back to the long conversation we had about this when it first came up... i agree with the wording that you said should be changed... but a particular trick is that the problem is not any image needing to be described, but particular complex images 17:47:23 ... we need to make a recommendation for how the UA should handle this information... and it should follow the standard rules... 17:48:03 q+ 17:48:05 ... whether by linking to existing docs in an existing spec or stating here that meaningful images should be described... we need to have it somehow 17:48:10 ack mattg 17:48:17 regrets+ geoff 17:48:50 q? 17:49:13 mattg: i fully agree, that was my intention that we'd link... but i'm wondering about how much we should repeat... i hate doing that because it tends to introduce ambiguity... but we could explicitly point what we mean about "meaningful images" to WCAG 17:49:55 q+ 17:50:02 dkaplan: i would be ok with the approach, but this is a difficult problem because this is a domain-specific aspect of the art of alt text that people don't understand... people don't usually understand that the cover contains metadata and images that are usually decorative, but not always 17:50:23 q? 17:50:28 this isn't just about books, is it? 17:50:29 ... WCAG does not explain this carefully... it's a set of guidelines, not about the art... it's domain-specific enough that it could use a little help 17:50:30 q+ 17:50:37 q+ 17:50:49 ... this is why i don't like the concept of "complex" (fractals are complex, but decorative, for example) 17:51:14 ack mattg 17:51:38 ack George 17:51:39 mattg: i completely agree with dkaplan, but we should raise it with WCAG about adding a technique, bringing publishing issues across W3C 17:51:40 matt: +100000090000 for technique for book covers!!! 17:52:08 +1 Agreed on book cover techniques! 17:52:11 also agreed with George: we called my CS book the dragon book, or sendmail the fruitbat book 17:52:12 ack Avneesh 17:52:17 George: i have seen times where students refer to the book by the cover image... and we need enough information so that we can identify the book... and i agree with pointing to WCAG guidelines and bringing this up with them 17:52:43 Avneesh: don't know if WCAG would be ready to absorb it right away, cover is so specific to publishing... but this could go into best practices too... not to decide yet 17:53:06 garth: this sounds like consensus.... mattg? 17:53:26 mattg: yes, this sounds like consensus, but we need to bring up a technique for covers with WCAG. these are the directions we can move forward with 17:53:35 garth: great, sounds like at least rough consensus 17:53:45 Topic: Path to CR 17:53:46 ... next item is path to CR... 17:53:51 https://github.com/w3c/publ-wg/wiki/%5BPublishing-WG%5D-CR-Transition-for-pub-manifest-and-audiobooks 17:54:19 ivan: the wiki page in fact reflects the questions that we would have to answer when we ask for permission to go to CR 17:54:37 ... there are lots of things there that have been collected, many things come from mattg like the changes, etc.... 17:54:59 ... first of all, i don't think the WG should say "yes" to all the things there, but it should reflect some sort of consensus of the group 17:55:12 ... we should review this and make sure the statements that are there reflect reality 17:55:52 ... we need an agreement on this. as far as i can see, unless mattg comes up with new issues, we have closed all the issues at least on pub manifest--i think also audiobooks--and there's some small editorial work to do, but i think we can say that the documents are ready 17:55:59 ... we can go ahead, but we need this consensus.... 17:56:23 ... what we also need, where things get complicated.... there's an implementation and testing strategy at the end of the page, but i am unsure whether what's there is good enough... 17:56:45 ... people who have more practice or volunteered could look at that text and give more details, because it sounds a little bit unclear 17:57:54 ... from the implementation side, the one thing that has happened in the past few weeks, and which should be mentioned, is that the processing of the manifest, a relatively complex algorithm that reflects all the MUSTS and SHOULDS, etc..., that does have two experimental implementations (in javascript and typescript)... and it's how we debugged the spec... but we should have more about that as well... 17:58:02 ... including what exactly we should test, etc. 17:58:11 ... just asking questions here... i don't have the answers 17:58:33 garth: talking a little about process... the things we need to do as a full WG as we're heading to the CR process... 17:59:08 ivan: formally speaking, the WG needs a formal resolution to ask the Director for authorization for CR... and part of doing that is pasting this document in an issue where it can be discussed 17:59:24 garth: so it's important to have everyone read that with the expectation to make the decision as a WG next week 17:59:44 ivan: correct, but we need some more information in the implementation part, otherwise we risk getting sent back to the drawing board 18:00:18 garth: next week we'll come back hopefully without issues to cover, discuss the wiki a little further, and hopefully have consensus for CR 18:00:56 rrsagent, draft minutes 18:00:56 I have made the request to generate https://www.w3.org/2019/11/04-pwg-minutes.html ivan