16:37:29 <RRSAgent> RRSAgent has joined #pwg
16:37:29 <RRSAgent> logging to https://www.w3.org/2019/03/04-pwg-irc
16:37:37 <Zakim> Zakim has joined #pwg
16:37:50 <tzviya> Meeting: PWG Weekly Telco
16:38:00 <tzviya> Chair: Wendy, Tzviya
16:38:11 <tzviya> Date: 2019-03-04
16:43:16 <tzviya> regrets+ Ivan
16:50:54 <jyoshii> jyoshii has joined #pwg
16:57:27 <tzviya> present+
16:57:35 <dkaplan3> present+
16:58:21 <geoffjukes> geoffjukes has joined #pwg
16:58:40 <NickRuffilo> NickRuffilo has joined #pwg
16:59:55 <dauwhe> present+
17:00:21 <bigbluehat> present+
17:00:39 <bigbluehat> scribenick: bigbluehat
17:00:45 <laudrain> laudrain has joined #pwg
17:00:48 <User2> User2 has joined #pwg
17:00:53 <gpellegrino> gpellegrino has joined #pwg
17:01:03 <Teenya> Teenya has joined #pwg
17:01:09 <Avneesh> Avneesh has joined #pwg
17:01:09 <josh> josh has joined #pwg
17:01:14 <gpellegrino> present+
17:01:22 <josh> present+
17:01:29 <franco> franco has joined #pwg
17:01:30 <Rachel> present+
17:01:35 <franco> present+
17:01:40 <Teenya> present+
17:01:54 <laudrain> present+
17:02:21 <Avneesh> present+
17:02:42 <bigbluehat> wendyreid: good morning all! have we done the minutes?
17:02:47 <bigbluehat> tzviya: not yet.
17:02:56 <wendyreid> https://www.w3.org/publishing/groups/publ-wg/Meetings/Minutes/2019/2019-02-25-pwg
17:03:06 <bigbluehat> wendyreid: here are the minutes from last time ^^
17:03:14 <bigbluehat> ...any comments, questions, changes?
17:03:18 <bigbluehat> ...k...minutes approved
17:03:26 <tzviya> RESOLVED: Minutes approved
17:03:42 <bigbluehat> wendyreid: first part of this meeting will be about audio issues
17:03:50 <david_stroup> david_stroup has joined #pwg
17:03:53 <bigbluehat> ...some of this is already done, but I'd still like to go over the proposals
17:03:57 <wendyreid> https://github.com/w3c/wpub/issues/351
17:04:04 <bigbluehat> Topic: Audio issues
17:04:09 <bigbluehat> Subtopic: 351
17:04:18 <bigbluehat> wendyreid: this was originally raised about synced media
17:04:26 <bigbluehat> ...the profile would use the type of "audiobook"
17:04:38 <bigbluehat> ...and other profiles would get their own classification (via this type)
17:04:42 <George> George has joined #pwg
17:04:48 <laurent_> laurent_ has joined #pwg
17:04:48 <George> present+ George
17:04:50 <bigbluehat> ...we would define new types when not already defined via schema.org
17:04:58 <laurent_> present+ laurent
17:04:58 <bigbluehat> ...and someone pointed out we can use wikidata for this
17:05:04 <dauwhe> github-bot, help
17:05:04 <github-bot> dauwhe, The commands I understand are:
17:05:04 <github-bot>   help      - Send this message.
17:05:04 <github-bot>   intro     - Send a message describing what I do.
17:05:05 <github-bot>   status    - Send a message with current bot status.
17:05:05 <github-bot>   bye       - Leave the channel.  (You can /invite me back.)
17:05:05 <github-bot>   end topic - End the current topic without starting a new one.
17:05:06 <github-bot>   reboot - Make me leave the server and exit.  If properly configured, I will then update myself and return.
17:05:34 <dauwhe> topic: https://github.com/w3c/wpub/issues/351
17:05:44 <bigbluehat> wendyreid: if there are no strong oppositions, then I'm going to close this as resolved
17:05:45 <dauwhe> Github: ttps://github.com/w3c/wpub/issues/351
17:05:52 <dauwhe> Github: https://github.com/w3c/wpub/issues/351
17:06:08 <rkwright> rkwright has joined #pwg
17:06:31 <rkwright> present+ rkwright
17:06:31 <wendyreid> Resolution: 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.
17:06:51 <bigbluehat> q+
17:06:56 <bigbluehat> q-
17:07:00 <bigbluehat> wendyreid: next issue
17:07:07 <wendyreid> https://github.com/w3c/wpub/issues/322
17:07:17 <bigbluehat> Topic: https://github.com/w3c/wpub/issues/322
17:07:25 <dauwhe> Github: https://github.com/w3c/wpub/issues/322
17:07:32 <bigbluehat> wendyreid: the proposal is to leave mixed media content outside of the reading order
17:07:41 <bigbluehat> ...but keep it in the resources list
17:07:51 <bigbluehat> ...so it doesn't get shown unecessarily
17:07:56 <bigbluehat> ...this would be a MUST
17:08:02 <bigbluehat> ...so only audio content would be in the reading order
17:08:07 <wendyreid> Resolution: 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.
17:08:07 <Teenya> Teenya has joined #pwg
17:08:09 <bigbluehat> ...everything else would be in the extra resources
17:08:13 <bigbluehat> q+
17:08:19 <wendyreid> ack bigbluehat
17:08:34 <NickRuffilo> scribenick: nickruffilo
17:08:43 <NickRuffilo> Benjamin: How does a reading system know to make use of any of these resources?
17:09:00 <marisa> marisa has joined #pwg
17:09:07 <Bill_Kasdorf> Bill_Kasdorf has joined #pwg
17:09:14 <marisa> present+
17:09:15 <NickRuffilo> Wendy: Really good question - and not one solved currently by audiobooks - we say if the user opens them they open them
17:09:17 <Bill_Kasdorf> present+ Bill_Kasdorf
17:09:51 <CHayes> CHayes has joined #pwg
17:10:02 <CHayes> present+
17:10:04 <NickRuffilo> Benjamin: I'm wondering how they know they are there.  Publications conceed 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
17:10:16 <tzviya> q+
17:10:16 <laurent_> q+
17:10:20 <NickRuffilo> ... so the reader or User Agent wouldn't know what to do with them.  That seems like - not like what is actually wanted here.
17:10:29 <wendyreid> ack tzviya
17:10:29 <NickRuffilo> Wendy: This came up - when we discussed last time...
17:10:39 <NickRuffilo> Scribenick: bigbluehat
17:10:48 <bigbluehat> tzviya: it's basically just saying here's a link to your thing
17:10:53 <bigbluehat> ...with no statements of how it should be displayed
17:11:01 <bigbluehat> ...we don't explain how to process links
17:11:05 <wendyreid> ack laurent_
17:11:06 <bigbluehat> ...and we don't need to get into the details of that
17:11:12 <bigbluehat> laurent_: in the example of a cover
17:11:18 <bigbluehat> ...there's a rel attribute that says this is a cover
17:11:25 <bigbluehat> ...the user agent will know what to do with that
17:11:32 <bigbluehat> ...it could be the same for a pdf containing something useful
17:11:41 <bigbluehat> ...we could create a vocabulary of uses
17:11:41 <George> q+
17:11:50 <wendyreid> ack George
17:11:50 <bigbluehat> ...to instruct the UA what it should do with them
17:11:54 <bigbluehat> ...without it being a requirement
17:12:02 <bigbluehat> George: if there's a MUST here for these not to be in the reading order
17:12:13 <bigbluehat> ...is there a MUST that they should be pointed to from a ToC?
17:12:19 <bigbluehat> ...otherwise how would they be utilized?
17:12:45 <bigbluehat> wendyreid: this is then related to the ToC conversation then
17:12:55 <bigbluehat> ...laurent_ brings up a really good point about the rel attributes
17:13:15 <bigbluehat> ...perhaps someone can make an issue for how to express supplemental content
17:13:19 <bigbluehat> laurent_: ok. I can do that
17:13:27 <bigbluehat> wendyreid: I think it deserves it's own discussion
17:13:37 <laurent_> q+
17:13:41 <wendyreid> ack laurent_
17:13:54 <bigbluehat> laurent_: I just wanted to say that a vocabular of rel as a best practice is useful
17:14:08 <bigbluehat> ...I think we shouldn't go toward excluding content
17:14:16 <bigbluehat> ...I will first open the rel attributes for audiobooks
17:14:45 <bigbluehat> wendyreid: I don't think this blocks the issue though from being closed
17:15:02 <bigbluehat> q+
17:15:16 <bigbluehat> scribenick: NickRuffilo
17:15:17 <Avneesh> Should we have another issue for George's recommendation
17:15:22 <wendyreid> ack bigbluehat
17:15:30 <NickRuffilo> scribenick: nickruffilo
17:15:32 <tzviya> I agree with wendyreid and ask George to open a new issue
17:15:33 <CharlesL> CharlesL has joined #pwg
17:15:41 <CharlesL> present+
17:15:52 <JunGamo> JunGamo has joined #pwg
17:15:53 <tzviya> q+
17:16:15 <NickRuffilo> Benjamin: 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...
17:16:50 <NickRuffilo> ... 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...
17:17:16 <LHulse> LHulse has joined #PWG
17:17:19 <NickRuffilo> ... 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.
17:17:21 <wendyreid> ack tzviya
17:17:26 <bigbluehat> scribenick: bigbluehat
17:17:33 <bigbluehat> tzviya: I want to be sure we don't backtrack
17:17:44 <bigbluehat> ...I believe we came to a conclusion about rel values in resources
17:17:54 <bigbluehat> ...I think we need to have that chat there, and not as part of this issue
17:18:03 <JunGamo> present+
17:18:10 <bigbluehat> ...we could ask the question about how a UA knows to render anything
17:18:19 <bigbluehat> ...we're focusing right now on whether the audio book profile
17:18:26 <bigbluehat> ...and what to do with these extra resources
17:18:35 <bigbluehat> ...and we should consider this in light of any web publication
17:18:45 <bigbluehat> ...right now, there's no specification about how these things are handled
17:18:54 <bigbluehat> ...my expectation is that these would simply open in a browser
17:19:11 <bigbluehat> ...but we should discuss these in the context of that rel issue
17:19:21 <bigbluehat> ...I think George should open that ToC issue, because that is a valid concern
17:19:33 <bigbluehat> wendyreid: George could you open an issue for your question then?
17:19:39 <bigbluehat> George: sure
17:19:52 <garth> garth has joined #pwg
17:20:01 <garth> present+ Garth
17:20:02 <wendyreid> https://github.com/w3c/wpub/issues/323
17:20:03 <tzviya> regrets+ Mateus
17:20:14 <bigbluehat> Topic: https://github.com/w3c/wpub/issues/323
17:20:28 <bigbluehat> wendyreid: this is about recommend formats for audiobooks
17:20:34 <bigbluehat> ...we plan to leave this in the hands of content creators
17:20:44 <bigbluehat> ...as discussed in the issue, by making this decisions
17:20:57 <bigbluehat> ...we also intend to point to something we can keep up to date
17:21:03 <wendyreid> 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.
17:21:14 <bigbluehat> ...but we don't want to proscribe what the industry is probably already doing for themselves
17:21:21 <dauwhe> q+
17:21:25 <wendyreid> ack dauwhe
17:21:30 <tzviya> s/proscribe/prescribe
17:21:51 <bigbluehat> dauwhe: one of the reasons we have specs at all is to facilitate interoperability
17:22:08 <bigbluehat> ...if I create something that follows the spec, then I can have some expectation that a supporting client can handle it
17:22:16 <bigbluehat> ...I fear we're bypassing interoperability here
17:22:31 <bigbluehat> ...if I make one using MP3, then do I risk it not being useful in some of the readers?
17:22:41 <bigbluehat> ...am I then required to read all the docs of all the readers to figure it out?
17:23:03 <bigbluehat> wendyreid: I think that's why we're hoping to have a living list of formats that we keep up to date long term
17:23:17 <bigbluehat> ...for instance, opus which is widely supported, but not supported by everyone would bethere
17:23:26 <tzviya> q+
17:23:29 <bigbluehat> ...but we don't want to limit it
17:23:30 <wendyreid> ack tzviya
17:23:36 <bigbluehat> tzviya: I did like Jeff's suggestion on github
17:23:46 <tzviya> S/Jeff/Geoff
17:23:59 <bigbluehat> ...limiting audio (and eventually video) to those things supported by the <audio> (and <video>) element
17:24:09 <bigbluehat> ...then it's not our fault for being to restrictive...it's those HTML people
17:24:10 <George> q+
17:24:15 <wendyreid> ack George
17:24:35 <bigbluehat> George: is there a notion here that an audio publisher would send to their distributor something that is not compressed?
17:24:48 <bigbluehat> ...and then the distributor figures out what they want for distribution?
17:24:57 <tzviya> guest+ Leslie_Hulse
17:25:20 <bigbluehat> wendyreid: geoffjukes might have a better perspective on that specifically
17:25:29 <bigbluehat> geoffjukes: we can deal with anything that fmpeg can read
17:25:42 <bigbluehat> ...but then we convert it to things our apps can understand
17:25:45 <bigbluehat> ...we accept anything right now
17:25:55 <bigbluehat> George: do you concern yourself with things that are encoded?
17:26:05 <bigbluehat> ...and then decode, and re-encode it at the risk of loss of quality?
17:26:15 <bigbluehat> geoffjukes: we have a list of preferred codecs in descending order
17:26:20 <bigbluehat> ...we prefer lossless first
17:26:30 <bigbluehat> ...all the way down to "or whatever you've got" (literally)
17:26:42 <bigbluehat> ...in the transcoding process we force it into a uniform output
17:27:09 <timCole> timCole has joined #pwg
17:27:09 <bigbluehat> ...so we encode it into M4A's for kobo and our apps, MP3s for audible, etc
17:27:24 <bigbluehat> ...doing this for audiobooks is less of an issue than doing this with orchestral music, for instance
17:27:33 <bigbluehat> wendyreid: is there any opposition to closing this issue
17:27:59 <wendyreid> 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. We will recommend the list of supported types under HTML5 <audio> specifications.
17:28:12 <bigbluehat> George: I don't see the resolution in the IRC
17:28:22 <bigbluehat> wendyreid: sorry, I'll re-read it
17:28:42 <Avneesh> HTML 5 has a broad list.
17:29:15 <Avneesh> q+
17:29:22 <wendyreid> ack Avneesh
17:29:38 <bigbluehat> Avneesh: I'm wondering why we did not settle on this 5-6 months ago (perhaps longer)?
17:29:44 <bigbluehat> ...that list was indeed long
17:29:52 <bigbluehat> ...and I don't remember what we discussed there previously
17:30:05 <bigbluehat> ...but we should discuss this with respect to interop, because the list is so huge
17:30:14 <bigbluehat> wendyreid: I'm trying to find that list
17:30:48 <bigbluehat> ...what we wanted to avoid was being overly restrictive and being overly broad
17:31:02 <bigbluehat> ...audio is big, and there are many different codecs
17:31:16 <bigbluehat> ...and its easier to point to something that's more up-to-date
17:31:27 <tzviya> https://www.w3.org/TR/html50/embedded-content-0.html#the-audio-element
17:32:34 <bigbluehat> https://www.w3.org/TR/html/embedded-content-0.html#the-audio-element
17:33:01 <bigbluehat> tzviya: point being that we can link out to something where its constantly maintained
17:33:16 <George> q+
17:33:21 <wendyreid> ack George
17:33:23 <bigbluehat> wendyreid: this is likely more maintainable than ours...and more up to date
17:33:37 <bigbluehat> George: my only concern is that these hardware players that people buy
17:33:46 <bigbluehat> ...don't have every codec in the world on there
17:33:53 <bigbluehat> ...and they have to license these codecs
17:34:19 <bigbluehat> ...maybe this isn't an issue, but distributing to them is something to consider
17:34:30 <bigbluehat> wendyreid: the hope is to bring this to the existing market
17:34:44 <bigbluehat> ...mostly audio publishers are distributing in popular formats: MP3, M4A
17:34:52 <bigbluehat> ...we're just bringing a unifying process to all this
17:35:02 <bigbluehat> ...except for the fact that they might be packaged
17:35:22 <bigbluehat> ...we do realize there will be future codecs
17:35:27 <bigbluehat> ...and we don't want to prevent those
17:36:01 <bigbluehat> tzviya: given the discussion, there's more to discuss, but are there any objections?
17:36:04 <bigbluehat> George: no objections
17:36:15 <laurent_> Most up to date link : https://caniuse.com/#feat=audio + sub-features
17:36:18 <bigbluehat> Topic: Use Cases and Requirements
17:36:29 <bigbluehat> tzviya: one of the things that publisher world has not always been fantastic about
17:36:35 <bigbluehat> ...is what happens for the User Agent
17:36:49 <bigbluehat> ...so I've asked Franco and Josh to lead a discussion about those expectations
17:37:04 <bigbluehat> ...and when we need implementers to start talking about this
17:37:09 <bigbluehat> ...we had been calling this affordances
17:37:15 <bigbluehat> ...but that word lead to some confusion
17:37:21 <bigbluehat> ...so we're now calling it behaviors
17:37:27 <bigbluehat> ...so, what happens when I do X
17:37:40 <bigbluehat> ...I also see that we have an agenda item for daylight savings time
17:37:49 <bigbluehat> ...this WG is going to stick with US time
17:37:55 <bigbluehat> ...so for everyone else, we're going to be 1 hour earlier
17:38:01 <bigbluehat> ...we'll make sure to highlight that in the agendas
17:38:12 <bigbluehat> ...franco take it away
17:38:21 <franco> * https://www.w3.org/TR/pwp-ucr/#uc_progresssion_device_sync
17:38:22 <bigbluehat> franco: I thought we'd review a few things tzviya linked to in the agenda
17:38:34 <bigbluehat> ...this is use case 78
17:38:47 <bigbluehat> ...I want to get into more practical discussions
17:39:04 <bigbluehat> ...this is the reader moving from a tablet to a phone
17:39:14 <bigbluehat> ...and she may not be using the same UA on both devices
17:39:29 <bigbluehat> ...this sort of bookmark or reading state moved across UAs
17:39:35 <bigbluehat> ...seems like an important use case
17:39:46 <bigbluehat> ...so I've explained some UA expectations
17:40:13 <josh> q+
17:40:34 <bigbluehat> ...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
17:41:02 <bigbluehat> josh: I wanted to further complicate the scenario for Aika to make a bookmark for this to work
17:41:14 <bigbluehat> ...progression should require me to click anything
17:41:23 <bigbluehat> ...if I'm in the apple ecosystem, then this just happens for me
17:41:35 <bigbluehat> ...so this is being stored for me...without my interaction
17:41:39 <tzviya> ack josh
17:41:49 <bigbluehat> ...so I'd suggest our first thing to point out is what that expectation is
17:41:52 <laudrain> +1 to josh
17:41:55 <garth> q+
17:41:55 <NickRuffilo> q+
17:41:58 <tzviya> ack garth
17:42:20 <bigbluehat> garth: that does not seem...if a reading system chooses to keep track of progression, that's all well and good
17:42:31 <bigbluehat> ...but I don't see how this would be an expectation for WP
17:42:43 <bigbluehat> ...so I don't think this is an appropriate expectation
17:42:43 <laudrain> q+
17:42:49 <bigbluehat> tzviya: so this isn't going in the spec
17:42:52 <bigbluehat> ...just the use case
17:42:53 <geoffjukes> +1 Progression would be a provider/distributor issue (not publisher)
17:42:58 <tzviya> ack NickRuffilo
17:43:07 <bigbluehat> garth: it's the point about this working across user agents which seemed inappropriate
17:43:30 <garth> q?
17:43:42 <bigbluehat> NickRuffilo: I realize physical and digital are completely different things
17:43:42 <laurent_> q+
17:43:52 <bigbluehat> ...but it would be neat to have some sort of pointer written into the file
17:43:57 <laurent_> q-
17:43:58 <bigbluehat> ...or some cache that persists with that file
17:44:06 <bigbluehat> ...or some sort of mechanism to persist these
17:44:19 <bigbluehat> q+ to note publication related requirements
17:44:26 <bigbluehat> ...but it has to live with this file
17:44:29 <garth> q?
17:44:30 <tzviya> ack laurent_
17:44:35 <bigbluehat> ...otherwise I can't imagine how else this would happen
17:44:35 <tzviya> ack laudrain
17:44:51 <bigbluehat> laudrain: I agree with NickRuffilo
17:44:59 <bigbluehat> ...the use case should be written differently
17:45:07 <bigbluehat> ...it's not a singular novel
17:45:13 <bigbluehat> ...she's reading a specific copy of that novel
17:45:13 <laurent_> q+
17:45:19 <bigbluehat> ...and it can be read in different UAs
17:45:30 <bigbluehat> ...and these two UAs should be able to understand the same position
17:45:46 <josh> q+
17:45:50 <tzviya> ack bigbluehat
17:45:50 <Zakim> bigbluehat, you wanted to note publication related requirements
17:47:06 <tzviya> ack laurent_
17:47:20 <bigbluehat> bigbluehat: the requirement is to point within the publication
17:47:25 <bigbluehat> ...sharing that or keeping that is beyond scope
17:47:35 <bigbluehat> laurent_: one way to do this is to standardize and API
17:47:48 <bigbluehat> ...or perhaps a slot within the publication to store personal information
17:47:53 <geoffjukes> q+
17:48:10 <bigbluehat> ...we the reading system can store some user-created JSON within the publication for reading state, etc.
17:48:38 <bigbluehat> ...I don't see how we can move from what we have done, a static manifest, to something dynamic to store additional information
17:48:44 <tzviya> q?
17:48:45 <bigbluehat> ...this all seems a bit far fetched isn't it?
17:48:46 <tzviya> ack josh
17:48:46 <bigbluehat> q+
17:49:07 <bigbluehat> josh: I think its fair to say we're talking about ecosystems
17:49:28 <bigbluehat> ...as a content host, I can't imagine that we would edit a product like a packaged web publication
17:49:41 <bigbluehat> ...or even having reserved space within a publication for personal information
17:49:53 <tzviya> q+
17:50:06 <bigbluehat> ...I can't imagine that anyone would want to rewrite the document to store that data
17:50:21 <rkwright> q+
17:50:32 <bigbluehat> ...doing it completely separate from the publication could make it shareable
17:50:47 <bigbluehat> ...whatever system we come up with though, I don't see this written into the publication itself
17:51:06 <bigbluehat> tzviya: josh you're saying this should happen externally of the publication
17:51:17 <bigbluehat> josh: yes. I wouldn't implement it by putting information into the epub
17:51:38 <bigbluehat> ...if I put a bookmark into the book, it doesn't appear in another book
17:51:59 <bigbluehat> ...so as a content provider, I don't want a lot of personalized copies of these publications
17:52:19 <bigbluehat> ...it would be much simpler to have a URL for pointing at these things
17:52:22 <tzviya> ack geoffjukes
17:52:31 <bigbluehat> tzviya: that might be a great way to get into discussions about implementions
17:52:53 <bigbluehat> josh: I have a URL of the web publication and I can access it and move through it
17:53:05 <bigbluehat> ...so I would want that URL to pair with my reading state
17:53:16 <bigbluehat> geoffjukes: josh said everything I want to say
17:53:25 <bigbluehat> ...repackaging things would not be something we'd want to do
17:53:35 <bigbluehat> ...we have callbacks that we manage through our own service
17:53:42 <tzviya> q?
17:53:52 <bigbluehat> ...if you want to figure out a standardized format, this might be a good use case for media fragments
17:53:57 <geoffjukes> https://www.w3.org/TR/media-frags/
17:54:08 <bigbluehat> ...I'm not sure how useful it is for non-media formats
17:54:19 <bigbluehat> ...it's a W3C spec for positions within media, basically
17:54:26 <tzviya> ack bigbluehat
17:54:34 <tzviya> q-
17:54:35 <bigbluehat> https://www.w3.org/TR/selectors-states/
17:54:44 <NickRuffilo> scribenick: nickruffilo
17:54:56 <bigbluehat> https://www.w3.org/TR/annotation-model/
17:55:18 <NickRuffilo> Benjamin: 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.
17:56:01 <NickRuffilo> ... 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.
17:56:48 <timCole> q+
17:56:49 <NickRuffilo> ... 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
17:57:04 <tzviya> ack rkwright
17:57:05 <NickRuffilo> ... but we need to address our inability to point within a publication, and not just "chapter5.html" stored somewhere
17:57:09 <bigbluehat> scribenick: bigbluehat
17:57:22 <bigbluehat> rkwright: two really really quick points
17:57:28 <bigbluehat> ...we don't want to modify the contents of a publication
17:57:31 <bigbluehat> ...users don't like it, etc
17:57:47 <bigbluehat> ...another thing about this is do we actually have people who want this?
17:57:50 <bigbluehat> ...I realize it's cool
17:57:55 <bigbluehat> ...and reading systems do this now
17:58:02 <bigbluehat> ...but across reading systems? won't ever happen
17:58:08 <tzviya> q?
17:58:11 <tzviya> ack timCole
17:58:14 <garth> +1 Ric
17:58:30 <bigbluehat> timCole: so just to mention there was a first public working draft for identifying within a publication
17:58:36 <josh> q+
17:58:37 <bigbluehat> ...it wasn't meant to change anything about the publication
17:58:42 <bigbluehat> ...but to point inside it
17:58:44 <tzviya> zakim, close the queue
17:58:44 <Zakim> ok, tzviya, the speaker queue is closed
17:58:49 <bigbluehat> ...including additional annotations, etc.
17:58:54 <bigbluehat> ...we should revisit that at some point
17:58:56 <tzviya> rrsagent, make logs public
17:59:20 <bigbluehat> ...there does need to be able to identify spots within the publication without changing the content
17:59:29 <bigbluehat> tzviya: we do need to look at it, but it's a huge topic
17:59:35 <tzviya> ack josh
17:59:38 <bigbluehat> ...we need to determine where it fits and how we might publish it
17:59:59 <evan> evan has joined #pwg
17:59:59 <bigbluehat> josh: despite earlier sort of suggesting this could work across UAs
18:00:10 <bigbluehat> ...while it'd be nice, these ecosystems don't share
18:00:28 <bigbluehat> ...they'd not be excited to make it just as easy to move between them
18:00:44 <bigbluehat> tzviya: we can focus on the one use case of staying in one ecosystem
18:01:13 <rkwright> without exception, my experience was that every single vendor wanted a walled garden.  Period. No sharing.  None.
18:01:17 <bigbluehat> ...what I'd really like to do is have some of the implementers look at these and express their needs
18:01:25 <bigbluehat> ...for instance, we never said what actually happens when you open a publication
18:01:36 <bigbluehat> ...and we need to address some of these expectations
18:01:57 <bigbluehat> tzviya: bye all
18:02:09 <JunGamo> JunGamo has left #pwg
18:02:13 <dkaplan3> dkaplan3 has left #pwg
18:05:39 <CharlesL> CharlesL has left #pwg
18:25:06 <dauwhe> dauwhe has joined #pwg
18:25:35 <dauwhe> dauwhe has joined #pwg
18:29:55 <Karen> Karen has joined #pwg