PWG Weekly Telco — Minutes

Date: 2019-03-04

See also the Agenda and the IRC Log

Attendees

Present: Tzviya Siegman, Deborah Kaplan, Dave Cramer, Benjamin Young, Gregorio Pellegrino, Joshua Pyle, Rachel Comerford, Franco Alvarado, Teenya Franklin, Luc Audrain, Avneesh Singh, George Kerscher, Laurent Le Meur, Ric Wright, Marisa DeMeglio, Bill Kasdorf, Caroline Hayes, Charles LaPierre, Jun Gamou, Garth Conboy

Regrets: Ivan Herman, Mateus Teixeira

Guests: Leslie Hulse

Chair: Wendy Reid, Tzviya Siegman

Scribe(s): Benjamin Young, Nick Ruffilo

Content:

Wendy Reid: good morning all! have we done the minutes?

Tzviya Siegman: not yet.

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

Wendy Reid: here are the minutes from last time ^^
… any comments, questions, changes?
… k…minutes approved

Resolution #1: Minutes of last week approved

1. Audio issues

Wendy Reid: first part of this meeting will be about audio issues
… some of this is already done, but I’d still like to go over the proposals

1.1. Issue #351: manifest JSON type property with AudioBook from Schema.org does NOT mean the “audio book” “kind”

Wendy Reid: https://github.com/w3c/wpub/issues/351

Wendy Reid: this was originally raised about synced media
… the profile would use the type of “audiobook”
… and other profiles would get their own classification (via this type)
… we would define new types when not already defined via schema.org
… and someone pointed out we can use wikidata for this

Wendy Reid: if there are no strong oppositions, then I’m going to close this as resolved

Resolution #2: Audiobook profile would use the type audiobook to declare to user agents the contents are primarily audio. For other types like SyncMedia or Comic, use custom classifications.

1.2. Issue #322: Mixed media in audiobook linear reading order

Wendy Reid: https://github.com/w3c/wpub/issues/322

Wendy Reid: the proposal is to leave mixed media content outside of the reading order
… but keep it in the resources list
… so it doesn’t get shown unnecessarily
… this would be a MUST
… so only audio content would be in the reading order

Resolution #3: Leave mixed media content out of the readingOrder and specify that supplemental content live in resources. This will allow it to be referenced in the TOC, but if a user agent cannot support it, it can be skipped.

Wendy Reid: everything else would be in the extra resources

Benjamin Young: How does a reading system know to make use of any of these resources?

Wendy Reid: Really good question — and not one solved currently by audiobooks — we say if the user opens them they open them

Benjamin Young: I’m wondering how they know they are there. Publications concede dependencies across multiple resources. The cover, additional notes, tabs, whatever you might want to put — because of that, there’s no binding or way to say where they go or how they should show up
… so the reader or User Agent wouldn’t know what to do with them. That seems like - not like what is actually wanted here.

Wendy Reid: This came up — when we discussed last time…

Tzviya Siegman: it’s basically just saying here’s a link to your thing
… with no statements of how it should be displayed
… we don’t explain how to process links
… and we don’t need to get into the details of that

Laurent Le Meur: in the example of a cover
… there’s a rel attribute that says this is a cover
… the user agent will know what to do with that
… it could be the same for a pdf containing something useful
… we could create a vocabulary of uses
… to instruct the UA what it should do with them
… without it being a requirement

George Kerscher: if there’s a MUST here for these not to be in the reading order
… is there a MUST that they should be pointed to from a ToC?
… otherwise how would they be utilized?

Wendy Reid: this is then related to the ToC conversation then
… laurent_ brings up a really good point about the rel attributes
… perhaps someone can make an issue for how to express supplemental content

Laurent Le Meur: ok. I can do that

Wendy Reid: I think it deserves it’s own discussion

Laurent Le Meur: I just wanted to say that a vocabulary of rel as a best practice is useful
… I think we shouldn’t go toward excluding content
… I will first open the rel attributes for audiobooks

Wendy Reid: I don’t think this blocks the issue though from being closed

Avneesh Singh: Should we have another issue for George’s recommendation

Tzviya Siegman: I agree with wendyreid and ask George to open a new issue

Benjamin Young: I think pivoting on types is dangerous and moves us away from the work we’ve done - and coming up wiht a generic model. We’re trending to n+1 possible types with possible processing instructions. If the RELs are valuable for cover, they can’t be best practices, they have to be known to the reading systems…
… It needs to be part of the data model if we expect it to be part of the data model - otherwise it is constructed however… I’m concerned with a lot of this being under specified and under-planned and not addressing accessibility and UA usage…
… and what the expected behavior would be if a UA sees this. You’d have a reading order thing, a resources thing, some of which is valuable, some of which is not - and it’s oddly constructed without clear intentions across different agents.

Tzviya Siegman: I want to be sure we don’t backtrack
… I believe we came to a conclusion about rel values in resources
… I think we need to have that chat there, and not as part of this issue
… we could ask the question about how a UA knows to render anything
… we’re focusing right now on whether the audio book profile
… and what to do with these extra resources
… and we should consider this in light of any web publication
… right now, there’s no specification about how these things are handled
… my expectation is that these would simply open in a browser
… but we should discuss these in the context of that rel issue
… I think George should open that ToC issue, because that is a valid concern

Wendy Reid: George could you open an issue for your question then?

George Kerscher: sure

1.3. Issue #323: List of recommended audio formats for audio-only WP

Wendy Reid: https://github.com/w3c/wpub/issues/323

Wendy Reid: this is about recommend formats for audiobooks
… we plan to leave this in the hands of content creators
… as discussed in the issue, by making this decisions
… we also intend to point to something we can keep up to date

Proposed resolution: The Audiobooks profile will not include a recommended list of audio formats for audiobooks. We will leave this in the hands of the content creators. (Wendy Reid)

Wendy Reid: but we don’t want to prescribe what the industry is probably already doing for themselves

Dave Cramer: one of the reasons we have specs at all is to facilitate interoperability
… if I create something that follows the spec, then I can have some expectation that a supporting client can handle it
… I fear we’re bypassing interoperability here
… if I make one using MP3, then do I risk it not being useful in some of the readers?
… am I then required to read all the docs of all the readers to figure it out?

Wendy Reid: I think that’s why we’re hoping to have a living list of formats that we keep up to date long term
… for instance, opus which is widely supported, but not supported by everyone would everywhere
… but we don’t want to limit it

Tzviya Siegman: I did like Geoff’s suggestion on github
… limiting audio (and eventually video) to those things supported by the <audio> (and <video>) element
… then it’s not our fault for being to restrictive…it’s those HTML people

George Kerscher: is there a notion here that an audio publisher would send to their distributor something that is not compressed?
… and then the distributor figures out what they want for distribution?

Wendy Reid: geoffjukes might have a better perspective on that specifically

Geoff Jukes: we can deal with anything that fmpeg can read
… but then we convert it to things our apps can understand
… we accept anything right now

George Kerscher: do you concern yourself with things that are encoded?
… and then decode, and re-encode it at the risk of loss of quality?

Geoff Jukes: we have a list of preferred codecs in descending order
… we prefer lossless first
… all the way down to “or whatever you’ve got” (literally)
… in the transcoding process we force it into a uniform output
… so we encode it into M4A’s for kobo and our apps, MP3s for audible, etc
… doing this for audiobooks is less of an issue than doing this with orchestral music, for instance

Wendy Reid: is there any opposition to closing this issue

Resolution #4: The Audiobooks profile will not include a recommended list of audio formats for audiobooks. We will leave this in the hands of the content creators. We will recommend the list of supported types under HTML5 <audio> specifications.

Avneesh Singh: HTML 5 has a broad list.

Avneesh Singh: I’m wondering why we did not settle on this 5-6 months ago (perhaps longer)?
… that list was indeed long
… and I don’t remember what we discussed there previously
… but we should discuss this with respect to interop, because the list is so huge

Wendy Reid: I’m trying to find that list
… what we wanted to avoid was being overly restrictive and being overly broad
… audio is big, and there are many different codecs
… and its easier to point to something that’s more up-to-date

Tzviya Siegman: https://www.w3.org/TR/html50/embedded-content-0.html#the-audio-element

Tzviya Siegman: point being that we can link out to something where its constantly maintained

Wendy Reid: this is likely more maintainable than ours…and more up to date

George Kerscher: my only concern is that these hardware players that people buy
… don’t have every codec in the world on there
… and they have to license these codecs
… maybe this isn’t an issue, but distributing to them is something to consider

Wendy Reid: the hope is to bring this to the existing market
… mostly audio publishers are distributing in popular formats: MP3, M4A
… we’re just bringing a unifying process to all this
… except for the fact that they might be packaged
… we do realize there will be future codecs
… and we don’t want to prevent those

Tzviya Siegman: given the discussion, there’s more to discuss, but are there any objections?

George Kerscher: no objections

Laurent Le Meur: Most up to date link : https://caniuse.com/#feat=audio + sub-features

2. Use Cases and Requirements

Tzviya Siegman: one of the things that publisher world has not always been fantastic about
… is what happens for the User Agent
… so I’ve asked Franco and Josh to lead a discussion about those expectations
… and when we need implementers to start talking about this
… we had been calling this affordances
… but that word lead to some confusion
… so we’re now calling it behaviors
… so, what happens when I do X
… I also see that we have an agenda item for daylight savings time
… this WG is going to stick with US time
… so for everyone else, we’re going to be 1 hour earlier
… we’ll make sure to highlight that in the agendas
… franco take it away

Franco Alvarado: https://www.w3.org/TR/pwp-ucr/#uc_progresssion_device_sync

Franco Alvarado: I thought we’d review a few things tzviya linked to in the agenda
… this is use case 78
… I want to get into more practical discussions
… this is the reader moving from a tablet to a phone
… and she may not be using the same UA on both devices
… this sort of bookmark or reading state moved across UAs
… seems like an important use case
… so I’ve explained some UA expectations
… uses an icon in the toolbar, stores it in a library somewhere, switches devices, opens the other UA, access that same library file via some sort of cloud mechanism, and her expectation is that the UA will take her to the same spot

Joshua Pyle: I wanted to further complicate the scenario for Aika to make a bookmark for this to work
… progression should require me to click anything
… if I’m in the apple ecosystem, then this just happens for me
… so this is being stored for me…without my interaction
… so I’d suggest our first thing to point out is what that expectation is

Luc Audrain: +1 to josh

Garth Conboy: that does not seem…if a reading system chooses to keep track of progression, that’s all well and good
… but I don’t see how this would be an expectation for WP
… so I don’t think this is an appropriate expectation

Tzviya Siegman: so this isn’t going in the spec
… just the use case

Geoff Jukes: +1 Progression would be a provider/distributor issue (not publisher)

Garth Conboy: it’s the point about this working across user agents which seemed inappropriate

Nick Ruffilo: I realize physical and digital are completely different things
… but it would be neat to have some sort of pointer written into the file
… or some cache that persists with that file
… or some sort of mechanism to persist these
… but it has to live with this file
… otherwise I can’t imagine how else this would happen

Luc Audrain: I agree with NickRuffilo
… the use case should be written differently
… it’s not a singular novel
… she’s reading a specific copy of that novel
… and it can be read in different UAs
… and these two UAs should be able to understand the same position

Benjamin Young: the requirement is to point within the publication
… sharing that or keeping that is beyond scope

Laurent Le Meur: one way to do this is to standardize and API
… or perhaps a slot within the publication to store personal information
… we the reading system can store some user-created JSON within the publication for reading state, etc.
… I don’t see how we can move from what we have done, a static manifest, to something dynamic to store additional information
… this all seems a bit far fetched isn’t it?

Joshua Pyle: I think its fair to say we’re talking about ecosystems
… as a content host, I can’t imagine that we would edit a product like a packaged web publication
… or even having reserved space within a publication for personal information
… I can’t imagine that anyone would want to rewrite the document to store that data
… doing it completely separate from the publication could make it shareable
… whatever system we come up with though, I don’t see this written into the publication itself

Tzviya Siegman: josh you’re saying this should happen externally of the publication

Joshua Pyle: yes. I wouldn’t implement it by putting information into the epub
… if I put a bookmark into the book, it doesn’t appear in another book
… so as a content provider, I don’t want a lot of personalized copies of these publications
… it would be much simpler to have a URL for pointing at these things

Tzviya Siegman: that might be a great way to get into discussions about implementations

Joshua Pyle: I have a URL of the web publication and I can access it and move through it
… so I would want that URL to pair with my reading state

Geoff Jukes: josh said everything I want to say
… repackaging things would not be something we’d want to do
… we have callbacks that we manage through our own service
… if you want to figure out a standardized format, this might be a good use case for media fragments (https://www.w3.org/TR/media-frags/)
… I’m not sure how useful it is for non-media formats
… it’s a W3C spec for positions within media, basically

Benjamin Young: https://www.w3.org/TR/selectors-states/

Benjamin Young: https://www.w3.org/TR/annotation-model/

Benjamin Young: There’s a much more limited form of the pointing to the full annotations data model spec. It can point to 1 or more things. What the web publication group would need is to have a way to point to a document within the publication.
… we don’t have a state of URL system that tells the system you are in a reading system or a position within a publication. In the annotation model, you can have a link to the 3rd paragraph of chapter 5 - so the UA might not know where that is or how to get there.
… so you need something that allows the UA to know that you’re within a reading context, and how to point to it. These are things we started to do earlier, but I’m not sure where we’re at at this point. I don’t think we should mix any of this into the storage of the publications
… but we need to address our inability to point within a publication, and not just “chapter5.html” stored somewhere

Ric Wright: two really really quick points
… we don’t want to modify the contents of a publication
… users don’t like it, etc
… another thing about this is do we actually have people who want this?
… I realize it’s cool
… and reading systems do this now
… but across reading systems? won’t ever happen

Garth Conboy: +1 Ric

Tim Cole: so just to mention there was a first public working draft for identifying within a publication (https://www.w3.org/TR/wpub-ann/)
… it wasn’t meant to change anything about the publication
… but to point inside it
… including additional annotations, etc.
… we should revisit that at some point
… there does need to be able to identify spots within the publication without changing the content

Tzviya Siegman: we do need to look at it, but it’s a huge topic
… we need to determine where it fits and how we might publish it

Joshua Pyle: despite earlier sort of suggesting this could work across UAs
… while it’d be nice, these ecosystems don’t share
… they’d not be excited to make it just as easy to move between them

Tzviya Siegman: we can focus on the one use case of staying in one ecosystem

Ric Wright: without exception, my experience was that every single vendor wanted a walled garden. Period. No sharing. None.

Tzviya Siegman: what I’d really like to do is have some of the implementers look at these and express their needs
… for instance, we never said what actually happens when you open a publication
… and we need to address some of these expectations

Tzviya Siegman: bye all

3. Resolutions