Publishing Working Group Telco — Minutes

Date: 2019-06-10

See also the Agenda and the IRC Log

Attendees

Present: Ivan Herman, Wendy Reid, Dave Cramer, Nick Ruffilo, Simon Collinson, Gregorio Pellegrino, Laurent Le Meur, Tim Cole, Luc Audrain, Franco Alvarado, Marisa DeMeglio, ben schroeter, Garth Conboy, Joshua Pyle, Ben Schroeter, George Kerscher, Avneesh Singh, Jun Gamou, Benjamin Young, Matt Garrish, Teenya Franklin, Brady Duga, Bill Kasdorf, Geoff Jukes, Charles LaPierre

Regrets: Tzviya Siegman, Romain Deltour

Guests:

Chair: Wendy Reid

Scribe(s): Dave Cramer, Benjamin Young, Wendy Reid

Content:

Wendy Reid: let’s get started

Wendy Reid: https://www.w3.org/publishing/groups/publ-wg/Meetings/Minutes/2019/2019-06-03-pwg

Wendy Reid: last weeks minutes are approved

Resolution #1: last weeks’ minutes are approved

1. recent updates to the WPUB spec

Wendy Reid: time to publish a new draft

Matt Garrish: there’s not too much that’s changed
… tag updates
… we were using a partial definition of webidl, and the tag didn’t like that
… so it’s all consolidated
… the other tag request was about address
… so we cleaned up some stuff
… and some changes to the algorithm
… pep has to always be available
… we still have a question about linking from resources to pep
… there was a change to toc algorithm
… before, we had the user agent take the string value of <a>, now we have option of using html children of <a>
… last change: removed some properties from a11y metadata
… they’re optional in epub, and we’re downplaying them; they’re not important for content
… ivan, you’ve made some changes to i18n

Ivan Herman: there was some clarification requested by the tag, and with the help from r12a
… the example table was changed
… there are discussions right now about base directions in json and json-ld that might affect the spec later.

Wendy Reid: so we have a new draft we should be publishing

Ivan Herman: we should

Proposed resolution: publish as WD the latest version of the Web Publications Editor’s Draft (Wendy Reid)

Ivan Herman: +1

Benjamin Young: +1

Franco Alvarado: +1

Tim Cole: +1

Bill Kasdorf: +1

Jun Gamou: +1

Ben Schroeter: +1

Laurent Le Meur: +1

Garth Conboy: +1

Luc Audrain: +1

Matt Garrish: +1

George Kerscher: +1

Resolution #2: publish as WD the latest version of the Web Publications Editor’s Draft

2. audiobooks

Wendy Reid: https://github.com/w3c/audiobooks/pull/4

Wendy Reid: I’ve done a pr for audiobooks
… this adds audioObject as discussed at f2f
… if everyone’s ok, we can merge this and then do fpwd

Ivan Herman: I have comment on pr
… which is essential
… right now doc says all things in reading order must be audio object
… which conflicts with wpub
… it should be possible to do both

Laurent Le Meur: in example in wp spec
… in c3, audiobook example, there is no type property on link object
… but ivan insists the type should be there
… should we in all examples add @type
… or should we decide that @type is optional

Ivan Herman: two things
… first, current situation is that canonicalization would add link type
… the reason that type is there, what happens is that schema.org complains if type for person is not there
… it’s required by schema.org
… we could decide it’s not required, but then we create an asymmetry
… and if schema.org later creates such a type, then we have a problem

Benjamin Young: have we considered getting linked resource into schema?
… it looks like a superset of most of what we need

Ivan Herman: there is an open issue somewhere
… the answer is yes and no
… there is an object defined by schema which is close to what we need
… and I raised this issue
… but there’s no way to add @rel to that object
… and it hasn’t been changed
… we should have a comment in our doc that this may disappear in favor of ?

Wendy Reid: we have a growing list of issues for schema.org
… we should be logging github issues and then emailing notifications

Ivan Herman: i’m happy to do so

Wendy Reid: in the meantime we don’t want this to stop us

Laurent Le Meur: we have a slight issue
… the link object has its own way to reference content
… and the audio object has a different way
… maybe we should add note to audio spec saying we’ll use properties from audio object

Wendy Reid: apparently we can map attributes like that
… so we could continue using url and have it map to content url
… so we stay consistent but schema is still happy

Benjamin Young: you can do that, but schema would be unhappy

Tim Cole: +1 bigbluehat

Benjamin Young: it’s like linking to a video–youtube has a video url to the page, but the content url is to the video format itself

Tim Cole: But might be a way to call their attention to this

Ivan Herman: but if we keep both for very good reasons then I think that the fpwd should make it clear why we do that
… what benjamin just said should be made clear for the reader

Benjamin Young: it could be in processing instructions for implementers
… then use content url even if there is also url

Wendy Reid: maybe we should hold off on audio object until we talk to schema
… I also see spec is using media object

Ivan Herman: it’s fine to publish fpwd without audio object, but have reference to the issue
… we need fpwd soon

Wendy Reid: I won’t merge the pr
… I’ll switch from mediaobject to linked resource, and include a note
… and then we can publish, if people have no objects

Ivan Herman: for fpwd we need a resolution to publish, and specifies the short name

Wendy Reid: did we do that at f2f

Ivan Herman: i don’t remember

Wendy Reid: I think we have short name of audiobooks (can’t hear punctuation on the phone)

Ivan Herman: -> https://www.w3.org/publishing/groups/publ-wg/Meetings/Minutes/2019/2019-05-06-pwg.html#resolution2 F2F resolution

Wendy Reid: i’ll do that this week

3. update on sync media

Marisa DeMeglio: 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

Marisa DeMeglio: I cleaned up the drafts after the f2f
… I extracted the issues into proper github issues
… and that’s where we’re at :)
… thanks for the comments on issues

Wendy Reid: can you summarize for people who might not have been at the f2f

Marisa DeMeglio: the issues were all over the place… it’s basically just changes to document organization

Wendy Reid: ok
… I hope everyone comments on the issues

4. finalizing UCR docs

Franco Alvarado: I opened a couple of issues for some of the requirements to get some feedback
… on whether things are duplicating existing html features

4.1. escalating trust

Wendy Reid: https://github.com/w3c/dpub-pwp-ucr/issues/217

Franco Alvarado: first was 217, escalating trust

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.

Franco Alvarado: I saw ivan and benjamin’s feedback

Benjamin Young: platforms seem to be more granular and contextual when asking for permission
… at what point does the publication need to encode what things it will need?
… does it happen at manifest level?
… or does the JS in a widget ask for a particular permission?

Franco Alvarado: maybe that granularity doesn’t need to be in the UCR? or into an explainer or the spec

Benjamin Young: the use case is publications asking for permissions
… those requests would be in implementations
… 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
… there should be a use case

Joshua Pyle: that makes sense, get permission only when you need it
… from the manifest, it might be good to specify all the things the script might ask for
… I would want to know in advance that the book might ask for microphone or geolocation

Benjamin Young: there’s a model for that in browser extensions
… (https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/Request_the_right_permissions)
… if you were to imagine a wp as a browser extension
… that could happen in lots of places
… there might be a use case that the content asks for that
… does the publication itself need more?

Dave Cramer: first of all, a web page asking for permissions is not the same thing as content requiring the use of that API
… lots of web pages ask me for my location, I say no
… I still get the content
… it might slow down my content experience
… but I still get the content
… I’m leery to add this sort of layer on top of the Web
… it introduces the opportunity for error about permissions
… I state that need this access, but I don’t actually use it
… so this seems at least inefficient and error prone

Joshua Pyle: the task for franco is to determine if this is already covered in the web
… we should probably mention use cases, but say that the web already provides such mechanisms

Ivan Herman: +1 to josh

Franco Alvarado: I don’t have an answer, but I wanted to bring up a use case

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.

Franco Alvarado: It doesn’t seem this is related to what the requirement is saying
… this is more like security… the origin of the wp

Wendy Reid: the web actually covers you in this case

Benjamin Young: we’re not only writing use cases for the web
… but also for other reading systems, outside of browsers
… must implementors do something to be conforming user agents?
… content can escalate trust
… reading systems need to be aware that this kind of thing can happen
… they go beyond what we spec because its in the content
… the use case needs to stay
… and also uc-12 may be in the wrong place

Joshua Pyle: not sure we’re all on the same page
… about whether everything that works on the web should work in wp
… so implementers need to use a browser
… and we shouldn’t start deleting use cases
… but we should state when we think the web already supports them

Franco Alvarado: I agree
… and I agree on moving uc-12
… and we can retain this use case

Franco Alvarado: 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.

Franco Alvarado: I think that ^ acknowledges that the web already does this. I’m ready to move on.

Wendy Reid: let’s do that

4.2. Resource mixing and CSS counters across HTML pages

Wendy Reid: https://github.com/w3c/dpub-pwp-ucr/issues/215

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

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.

Franco Alvarado: this is from tag review
… they thought this contradicted something in our docs
… and this is not possible in css today

Brady Duga: there is a contradiction. I don’t like this use case, because it’s not talking about functionality
… we’re talking about a specific technology. that’s dictating a solution.
… practically, having this is not going to be feasible
… we could ditch the use case
… implementing this would be a nightmare

Franco Alvarado: that sounds good to me

Ric Wright: +1 duga

Franco Alvarado: the requirement is something that’s not possible on the web
… I could see something with floats if you’re stitching together across spreads
… it seems like we don’t need to specify

Ivan Herman: I agree with brady that we should separate the implementation from the use case; it should be reformulated without reference to css
… 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
… maybe we can convince css folks it’s of interest, or the superdom :)
… we should not remove a use case because it can’t be implemented

Bill Kasdorf: +1 to Ivan

Luc Audrain: there’s an issue between the use case and the example
… there’s a question about multiple resources in the same rendering
… but the counters thing is very important; doesn’t talk about rendering
… it’s strange to mix these things
… but I agree with ivan, we should not delete the use case

Brady Duga: does the use case require that this happen automatically?
… or is it good enough to be able to specify what those numbers should be?
… automatic or not?

Bill Kasdorf: this is a common issue wrt footnotes, endnotes, and references, but imo they can be explicit in the content per duga

Franco Alvarado: We’re running out of time, I would like more feedback on this issue, please add to the comments

Wendy Reid: We’ll move this to next week and please comment in the meantime

5. Resolutions