15:42:24 <RRSAgent> RRSAgent has joined #pwg
15:42:24 <RRSAgent> logging to https://www.w3.org/2019/06/10-pwg-irc
15:42:25 <ivan> rrsagent, set log public
15:42:25 <ivan> Meeting: Publishing Working Group Telco
15:42:25 <ivan> Chair: wendy
15:42:25 <ivan> Date: 2019-06-10
15:42:25 <ivan> Agenda: https://lists.w3.org/Archives/Public/public-publ-wg/2019Jun/0005.html
15:42:25 <ivan> ivan has changed the topic to: Meeting Agenda 2019-06-10: https://lists.w3.org/Archives/Public/public-publ-wg/2019Jun/0005.html
15:42:26 <ivan> Regrets+ tzviya, rdeltour
15:53:44 <NickRuffilo> NickRuffilo has joined #pwg
15:56:37 <simon_collinson> simon_collinson has joined #pwg
15:57:55 <ivan> present+
15:57:58 <wendyreid> present+
15:58:05 <dauwhe> present+
15:58:18 <ivan> present+ NickRuffilo, simon_collinson
15:59:34 <gpellegrino> gpellegrino has joined #pwg
15:59:45 <gpellegrino> present+
15:59:51 <timCole> timCole has joined #pwg
16:00:08 <rkwright> rkwright has joined #pwg
16:00:21 <laurent> laurent has joined #pwg
16:00:28 <laurent> present+ laurent
16:00:39 <franco> franco has joined #pwg
16:00:43 <laudrain> laudrain has joined #pwg
16:00:47 <ivan> present+ timCole
16:00:56 <laudrain> present+
16:00:57 <franco> present+
16:01:04 <Avneesh> Avneesh has joined #pwg
16:01:51 <josh> josh has joined #pwg
16:01:52 <marisa> marisa has joined #pwg
16:01:55 <garth> garth has joined #pwg
16:02:05 <marisa> present+
16:02:06 <BenSchroeter> BenSchroeter has joined #pwg
16:02:07 <George> George has joined #pwg
16:02:11 <ivan> present+ Ben_Schroeter
16:02:14 <garth> present+ Garth
16:02:14 <josh> present+
16:02:16 <dauwhe> scribenick: dauwhe
16:02:18 <BenSchroeter> present+
16:02:21 <George> present+
16:02:26 <dauwhe> wendyreid: let's get started
16:02:33 <JunGamo> JunGamo has joined #pwg
16:02:33 <wendyreid> https://www.w3.org/publishing/groups/publ-wg/Meetings/Minutes/2019/2019-06-03-pwg
16:02:34 <Avneesh> present+
16:02:41 <JunGamo> present+
16:02:56 <dauwhe> ... last weeks minutes are approved
16:03:07 <ivan> resolved: last weeks' minutes are approved
16:03:20 <dauwhe> Topic: recent updates to spec
16:03:24 <mgarrish> mgarrish has joined #pwg
16:03:30 <dauwhe> wendyreid: time to publish a new draft
16:03:39 <bigbluehat> present+
16:03:40 <dauwhe> mgarrish:
16:03:46 <dauwhe> ...
16:03:47 <dauwhe> ...
16:04:15 <mgarrish> present+
16:04:47 <dauwhe> mgarrish: there's not too much that's changed
16:04:53 <dauwhe> ... tag updates
16:05:19 <dauwhe> ... we were using a partial definition of webidl, and the tag didn't like that
16:05:22 <duga> duga has joined #pwg
16:05:22 <Teenya> Teenya has joined #pwg
16:05:24 <dauwhe> ... so it's all consolidated
16:05:34 <Teenya> present+
16:05:54 <dauwhe> ... the other tag request was about address
16:06:06 <dauwhe> ... so we cleaned up some stuff
16:06:12 <dauwhe> ... and some changes to the algorithm
16:06:30 <ivan> present+ josh
16:06:32 <dauwhe> ... pep has to always be available
16:06:38 <duga> present+
16:07:22 <dauwhe> ... we still have a question about linking from resources to pep
16:07:35 <Bill_Kasdorf> Bill_Kasdorf has joined #pwg
16:07:44 <Bill_Kasdorf> present+
16:07:50 <dauwhe> ... there was a change to toc algo
16:08:30 <ivan> present+ bigbluehat
16:09:14 <dauwhe> ... before, we had the user agent take the string value of <a>, now we have option of using html children of <a>
16:09:23 <dauwhe> ... last change: removed some properties from a11y metadata
16:09:25 <geoffjukes> geoffjukes has joined #pwg
16:09:57 <ivan> present+ geoffjukes
16:10:03 <dauwhe> ... they're optional in epub, and we're downplaying them; they're not important for content
16:10:12 <ivan> q+
16:10:21 <dauwhe> ... ivan, you've made some changes to i18n
16:10:24 <wendyreid> ack ivan
16:10:30 <CharlesL> CharlesL has joined #pwg
16:10:36 <CharlesL> present+
16:10:38 <dauwhe> ivan: there was some clarification requested by the tag, and hellp from r12a
16:10:43 <dauwhe> ... the diagram was changed
16:11:03 <dauwhe> ... there are discussions right now about directions for json and json=ld
16:11:40 <dauwhe> wendyreid: so we have a new draft we should be publishing
16:11:42 <dauwhe> ivan: we should
16:12:04 <wendyreid> Proposal: Ship the latest version of the Web Publications Editor's Draft
16:12:08 <ivan> +1
16:12:10 <bigbluehat> +1
16:12:16 <franco> +1
16:12:18 <timCole> +1
16:12:19 <Bill_Kasdorf> +1
16:12:20 <JunGamo> +1
16:12:21 <BenSchroeter> +1
16:12:22 <laurent> +1
16:12:23 <garth> +1
16:12:28 <laudrain> +1
16:12:30 <dauwhe> dauwhe: by shipping do you mean publishing as a WD?
16:12:32 <mgarrish> +1
16:12:32 <dauwhe> wendyreid: yes
16:12:44 <wendyreid> RESOLVED: Ship the latest version of the Web Publications Editor's Draft
16:12:55 <dauwhe> s/ship/publish as WD/
16:12:59 <George> +1
16:13:05 <dauwhe> Topic: audiobooks
16:13:09 <wendyreid> https://github.com/w3c/audiobooks/pull/4
16:13:14 <dauwhe> wendyreid: I've done a pr for audiobooks
16:13:32 <dauwhe> ... this adds audioObject as discussed at f2f
16:13:56 <ivan> q+
16:14:00 <wendyreid> ack ivan
16:14:01 <dauwhe> ... if everyone's ok, we can merge this and then do fpwd
16:14:06 <dauwhe> ivan: I have comment on pr
16:14:11 <dauwhe> ... which is essential
16:14:26 <dauwhe> ... right now doc says all things in reading order must be audioobject
16:14:32 <dauwhe> ... which conflicts with wpub
16:14:48 <laurent> q+
16:14:49 <dauwhe> ... it should be possible to do both
16:14:51 <wendyreid> ack laurent
16:15:03 <dauwhe> laurent: in example in wp spec
16:15:19 <dauwhe> ... in c3, audiobook example, there is no type property on link object
16:15:33 <ivan> q+
16:15:39 <dauwhe> ... but ivan insists the type is there
16:15:47 <dauwhe> ... should we in all examples add @type
16:15:56 <dauwhe> ... or should we decide that @type is optional
16:16:21 <wendyreid> ack ivan
16:16:25 <dauwhe> ivan: two things
16:16:37 <dauwhe> ... first, current situation is that canonicalization would add link type
16:17:07 <dauwhe> ... the reason that type is there, what happens is that schema.org complains if type for person is not there
16:17:18 <dauwhe> ... it's required by schema.org
16:17:38 <dauwhe> ... we could decide it's not required, but then we create an asymmetry
16:17:51 <dauwhe> ... and if schema.org later creates such a type, then we have a problem
16:18:18 <bigbluehat> q+
16:18:23 <wendyreid> ack bigbluehat
16:18:41 <dauwhe> bigbluehat: have we considered getting linkedresource into schema?
16:18:52 <ivan> q+
16:18:59 <dauwhe> ... it looks like a superset of most of what we need
16:19:02 <wendyreid> ack ivan
16:19:08 <dauwhe> ivan: there is an open issue somewhere
16:19:17 <dauwhe> ... the answer is yes and no
16:19:28 <dauwhe> ... there is an object defined by schema which is close to what we need
16:19:36 <dauwhe> ... and I raised this issue
16:19:45 <dauwhe> ... but there's no way to add @rel to that object
16:19:56 <dauwhe> ... and it hasn't been changed
16:20:35 <dauwhe> ... we should have a comment in our doc that this may disappear in favor of ?
16:20:43 <dauwhe> wendyreid: we have a growing list of issues for schema.org
16:21:06 <dauwhe> ... we should be logging github issues and then emailing notifications
16:21:11 <dauwhe> ivan: i'm happy to do so
16:21:30 <dauwhe> wendyreid: in the meantime we don't want this to stop us
16:21:38 <laurent> q+
16:21:45 <wendyreid> ack laurent
16:21:49 <dauwhe> laurent: we have a slight issue
16:21:59 <dauwhe> ... the link object has its own way to reference content
16:22:06 <dauwhe> ... and the audio object has a different way
16:22:31 <dauwhe> ... maybe we should add note to audiospec saying we'll use properties from audiobject
16:22:41 <dauwhe> wendyreid: apparently we can map attributes like that
16:22:50 <garth> q?
16:22:52 <dauwhe> ... so we could continue using url and have it map to contenturl
16:22:59 <bigbluehat> q+
16:23:06 <wendyreid> ack bigbluehat
16:23:06 <dauwhe> ... so we stay consistent but schema is still happy
16:23:15 <dauwhe> bigbluehat: you can do that, but schema would be unhappy
16:23:30 <timCole> +1 bigbluehat
16:23:51 <dauwhe> ... it's like linking to a video--youtube has a video url to the page, but the contenturl is to the video format itself
16:24:17 <ivan> q+
16:24:22 <wendyreid> ack ivan
16:24:27 <timCole> But might be a way to call their attention to this
16:24:45 <bigbluehat> q+
16:24:49 <dauwhe> ivan: but if we keep both for very good reasons then I think that the fpwd should make it clear why we do that
16:24:59 <dauwhe> ... what benjamin just said should be made clear for the reader
16:25:00 <wendyreid> ack bigbluehat
16:25:13 <dauwhe> bigbluehat: it could be in processing instructions for implementers
16:25:28 <dauwhe> ... then use contenturl even if there is also url
16:26:21 <dauwhe> wendyreid: maybe we should hold off on audioobject until we talk to schema
16:26:36 <ivan> q+
16:26:43 <dauwhe> ... I also see spec is using mediaobject
16:26:43 <wendyreid> ack ivan
16:27:01 <dauwhe> ivan: it's fine to publish fpwd without audiobject, but have reference to the issue
16:27:12 <dauwhe> ... we need fpwd soon
16:27:17 <dauwhe> wendyreid: I won't merge the pr
16:27:33 <dauwhe> ... I'll switch from mediaobject to linkedresource, and include a note
16:27:56 <dauwhe> ... and then we can publish, if people have no objects
16:28:09 <dauwhe> ivan: for fpwd we need a resolution to publish, and specifies the shortname
16:28:15 <dauwhe> wendyreid: did we do that at f2f
16:28:20 <dauwhe> ivan: i don't remember
16:28:47 <dauwhe> wendyreid: I think we have short name of audiobooks (can't hear punctuation on the phone)
16:29:40 <ivan> -> https://www.w3.org/publishing/groups/publ-wg/Meetings/Minutes/2019/2019-05-06-pwg.html#resolution2 F2F resolution
16:29:52 <dauwhe> wendyreid: i'll do that this week
16:30:09 <dauwhe> Topic: update on sync media
16:30:26 <dauwhe> marisa: i cleaned up the drafts after the f2f
16:30:35 <dauwhe> ... I extracted the issues into proper github issues
16:30:44 <dauwhe> ... and that's where we're at :)
16:31:07 <marisa> https://w3c.github.io/sync-media-pub/narration.html, https://w3c.github.io/sync-media-pub/packaging.html, https://github.com/w3c/sync-media-pub/issues
16:31:09 <dauwhe> ... thanks for the comments on issues
16:31:43 <dauwhe> wendyreid: can you summarize for people who might not have been at the f2f
16:32:01 <dauwhe> marisa: the issues were all over the place... it's basically just changes to document organization
16:32:03 <dauwhe> wendyreid: ok
16:32:24 <dauwhe> ... I hope everyone comments on the issues
16:32:34 <dauwhe> topic: finalizing UCR docs
16:32:57 <dauwhe> franco: I opened a couple of issues for some of the requirements to get some feedback
16:33:10 <dauwhe> ... on whether things are duplicating existing html features
16:33:19 <dauwhe> ... first was 217, escalating grust
16:33:26 <dauwhe> s/grust/trust/ :)
16:33:44 <wendyreid> https://github.com/w3c/dpub-pwp-ucr/issues/217
16:33:51 <franco> User agents may provide a method for escalating trust for a specific publication. Some publications may require additional capabilities (for example, access to camera or geolocation) that a user agent might normally not enable. Today, some platform and UA vendors offer methods for otherwise untrusted local scripts to become trusted and regain API privileges, a similar ability needs to exist for publications as well.
16:34:15 <dauwhe> ... I saw ivan and benjamin's feedback
16:34:23 <bigbluehat> q+
16:34:26 <wendyreid> ack bigbluehat
16:35:19 <dauwhe> bigbluehat: platforms seem to be more granular and contextual when asking for permission
16:35:34 <dauwhe> ... at what point does the publication need to encode what things it will need?
16:35:44 <dauwhe> ... does it happen at manifest level?
16:35:59 <dauwhe> ... or does the JS in a widget ask for a particular permission?
16:36:34 <bigbluehat> q+
16:36:47 <wendyreid> ack bigbluehat
16:36:48 <dauwhe> franco: maybe that granularity doesn't need to be in the UCR? or into an explainer or the spec
16:36:58 <dauwhe> bigbluehat: the use case is publications asking for permissions
16:37:11 <dauwhe> ... those requests would be in implementations
16:37:44 <josh> q+
16:38:02 <dauwhe> ... if there was permission needed to ask for bluetooth, then there's a moment that the content makes the request, and consent from user sent back to content
16:38:08 <wendyreid> ack josh
16:38:09 <dauwhe> ... there should be a use case
16:38:23 <dauwhe> josh: that makes sense, get permission only when you need it
16:38:41 <dauwhe> ... from the manifest, it might be good to specify all the things the script might ask for
16:38:45 <bigbluehat> q+ to point at https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/Request_the_right_permissions
16:39:01 <dauwhe> ... I would want to know in advance that the book might ask for microphone or geolocation
16:39:06 <dauwhe> q+
16:39:07 <garth> q?
16:39:14 <wendyreid> ack bigbluehat
16:39:14 <Zakim> bigbluehat, you wanted to point at https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/Request_the_right_permissions
16:39:30 <dauwhe> bigbluehat: there's a model for that in browser extensions
16:39:47 <dauwhe> ... if you were to imagine a wp as a browser extension
16:40:06 <dauwhe> ... that could happen in lots of places
16:40:22 <dauwhe> ... there might be a use case that the content asks for that
16:40:35 <josh> q+
16:40:42 <dauwhe> ... does the publication itself need more?
16:40:47 <wendyreid> ack dauwhe
16:40:55 <bigbluehat> scribe+ bigbluehat
16:41:11 <bigbluehat> dauwhe: first of all, a web page asking for permissions is not the same thing as content requiring the use of that API
16:41:19 <bigbluehat> ...lots of web pages ask me for my location, I say no
16:41:22 <bigbluehat> ...I still get the content
16:41:33 <bigbluehat> ...it might slow down my content experience
16:41:37 <bigbluehat> ...but I still get the content
16:41:47 <bigbluehat> ...I'm leery to add this sort of layer on top of the Web
16:41:56 <garth> q?
16:41:57 <bigbluehat> ...it introduces the opportunity for error about permissions
16:42:09 <bigbluehat> ...I state that need this access, but I don't actually use it
16:42:23 <wendyreid> ack josh
16:42:25 <bigbluehat> ...so this seems at least inefficient and error prone
16:42:48 <franco> q+
16:42:53 <dauwhe> josh: the task for franco is to determine if this is already covered in the web
16:43:09 <dauwhe> ... we should probably mention use cases,but say that the web already provides such mechanisms
16:43:12 <dauwhe> q?
16:43:16 <wendyreid> ack franco
16:43:16 <ivan> +1 to josh
16:43:32 <dauwhe> franco: I don't have an answer, but I wanted to bring up a use case
16:43:37 <franco> UC 12: Luke has written another book, this time using all of the capabilities of the Open Web Platform that he can think of including using the readers location to adapt the content. He submits the book for review to a Web Publication retail platform, where the book is signed by the publisher. When purchased, the UA detects that the book came from a trusted source and has not been modified, therefore allowing it to use the full capabilities of the web platform.
16:44:10 <dauwhe> ... It doesn't seem this is related to what the requirement is saying
16:44:24 <dauwhe> ... this is more like security... the origin of the wp
16:44:33 <Karen> Karen has joined #pwg
16:44:40 <bigbluehat> q+
16:44:41 <dauwhe> wendyreid: the web actually covers you in this case
16:44:48 <wendyreid> ack BenSchroeter
16:44:51 <wendyreid> ack bigbluehat
16:44:59 <dauwhe> bigbluehat: we're not only writing use cases for the web
16:45:24 <dauwhe> ... but also for other reading systems, outside of browsers
16:45:54 <dauwhe> ... must implementors do something to be conforming user agents?
16:45:54 <josh> q+
16:46:27 <dauwhe> ... content can escalate trust
16:46:29 <ivan_> ivan_ has joined #pwg
16:46:44 <dauwhe> ... reading systems need to be aware that this kind of thing can happen
16:47:04 <dauwhe> ... they go beyond what we spec because its in the content
16:47:17 <dauwhe> ... the use case needs to stay
16:47:29 <dauwhe> ... and also uc-12 may be in the wrong place
16:47:37 <wendyreid> ack josh
16:47:50 <dauwhe> josh: not sure we're all on the same page
16:48:21 <dauwhe> ... about whether everything that works on the web should work in wp
16:48:27 <dauwhe> ... so implementers need to use a browser
16:48:34 <dauwhe> ... and we shouldn't start deleting use cases
16:48:47 <dauwhe> ... but we should state when we think the web already supports them
16:48:59 <franco> q+
16:49:04 <wendyreid> ack franco
16:49:11 <dauwhe> franco: I agree
16:49:17 <dauwhe> ... and I agree on moving uc-12
16:49:25 <dauwhe> ... and we can retain this use case
16:49:34 <franco> Today, some platform and UA vendors offer methods for otherwise untrusted local scripts to become trusted and regain API privileges, a similar ability needs to exist for publications as well.
16:49:57 <dauwhe> ... I think that ^ acknowledges that the web already does this. I'm ready to move on.
16:50:01 <dauwhe> wendyreid: let's do that
16:50:05 <dauwhe> franco: #215
16:50:17 <wendyreid>  https://github.com/w3c/dpub-pwp-ucr/issues/215
16:50:26 <franco> For the purposes of layout, each resource of a Web Publication is treated as a separate document. User agents must not mix content from multiple resources in the same rendering (e.g., CSS floats or absolutely positioned elements from one resource cannot intrude or overlap with content from an other resource).
16:50:31 <franco> Maeve is authoring an internal work document for her company as a Web Publication. This Web Publication spans several resources / documents, and she would like to use decimal-dot notation to indicate the section numbers. The CSS counter should be able to accumulate across the multiple resources to provide an accurate count.
16:50:32 <dauwhe> franco: this is from tag review
16:51:26 <dauwhe> ... they thought this contradicted something in our docs
16:51:34 <garth> q?
16:51:44 <duga> q+
16:52:05 <dauwhe> ... and this is not possible in css today
16:52:12 <wendyreid> ack duga
16:52:28 <dauwhe> duga: there is a contradiction. I don't like this use case, because it's not talking about functionality
16:52:44 <dauwhe> ... we're talking about a specific technology. that's dictating a solution.
16:52:57 <dauwhe> ... practically, having this is not going to be feasible
16:53:03 <dauwhe> ... we could ditch the use case
16:53:13 <franco> q+
16:53:23 <dauwhe> ... implementing this would be a nightmare
16:53:23 <wendyreid> ack franco
16:53:30 <dauwhe> franco: that sounds good to me
16:53:38 <bigbluehat> q+
16:53:38 <ivan_> q+
16:53:45 <rkwright> +1 duga
16:53:45 <dauwhe> ... the requirement is something that's not possible on the web
16:53:46 <bigbluehat> q-
16:53:51 <laudrain> q+
16:53:53 <dauwhe> q+
16:54:26 <dauwhe> franco: I could see something with floats if you're stitching together across spreads
16:54:41 <dauwhe> ... it seems like we don't need to specify
16:54:41 <wendyreid> ack ivan
16:55:01 <dauwhe> ivan: I agree with brady that we should separate the implementation from the use case; it should be reformulated without reference to css
16:55:25 <dauwhe> ... the fact that it can't be done on the web today is a sad reality,but it doesn't mean that it can't be a use case
16:55:43 <dauwhe> ... maybe we can convince css folks it's of interest, or the superdom :)
16:55:48 <wendyreid> ack laudrain
16:55:56 <dauwhe> ... we should not remove a use case because it can't be implemented
16:55:57 <Bill_Kasdorf> +1 to Ivan
16:56:07 <dauwhe> laudrain: there's an issue between the use case and the example
16:56:38 <dauwhe> ... there's a question about multiple resources in the same rendering
16:56:56 <dauwhe> ... but the counters thing is very important; doesn't talk about rendering
16:57:04 <dauwhe> ... it's strange to mix these things
16:57:16 <dauwhe> ... but I agree with ivan, we should not delete the use case
16:57:17 <duga> q+
16:57:18 <dauwhe> q-
16:57:25 <franco> q+
16:57:31 <wendyreid> ack duga
16:57:49 <dauwhe> duga: does the use case require that this happen automatically?
16:58:07 <laudrain> q+
16:58:07 <dauwhe> ... or is it good enough to be able to specify what those numbers should be?
16:58:15 <dauwhe> ... automatic or not?
16:58:35 <wendyreid> ack franco
16:58:52 <laudrain> q-
16:58:57 <wendyreid> scribe + wendyreid
16:59:04 <Bill_Kasdorf> this is a common issue wrt footnotes, endnotes, and references, but imo they can be explicit in the content per duga
16:59:20 <wendyreid> franco: We're running out of time, I would like more feedback on this issue, please add to the comments
17:00:02 <CharlesL> CharlesL has left #pwg
17:00:04 <wendyreid> wendyreid: We'll move this to next week and please comment in the meantime
17:00:18 <JunGamo> JunGamo has left #pwg
17:00:23 <ivan> rrsagent, draft minutes
17:00:23 <RRSAgent> I have made the request to generate https://www.w3.org/2019/06/10-pwg-minutes.html ivan