14:03:03 <RRSAgent> RRSAgent has joined #dpub-loc
14:03:03 <RRSAgent> logging to http://www.w3.org/2016/03/16-dpub-loc-irc
14:03:10 <lrosenth> lrosenth has joined #dpub-loc
14:03:13 <bjdmeest> rssagent, pointer?
14:03:56 <lrosenth> present+ Leonard
14:04:06 <bjdmeest> Present+ Ben_De_Meester
14:05:48 <bjdmeest> scribenick bjdmeest
14:06:16 <bjdmeest> https://github.com/w3c/dpub-pwp-loc/issues/9
14:06:22 <bjdmeest> Topic: Issue 9
14:07:51 <bjdmeest> ivan: about arbitrary resource within a packed PWP
14:08:03 <bjdmeest> ... if no unpacked version, this will give a 404
14:08:33 <bjdmeest> lrosenth: given the server cannot process the packed PWP
14:08:46 <bjdmeest> ivan: this proposal is algorithmically ok
14:08:52 <bjdmeest> ... but not realistic to set up
14:09:10 <bjdmeest> lrosenth: or the server could dynamically return the resource
14:09:24 <bjdmeest> ivan: then you wouldn't get a 404
14:09:51 <bjdmeest> lrosent: so you need a PWP-aware server
14:09:57 <bjdmeest> ivan: could be done via .htaccess
14:10:15 <bjdmeest> lrosenth: it is possible
14:10:22 <bjdmeest> ivan: viable, but not realistic
14:11:16 <bjdmeest> bjdmeest: so nothing more than a 404?
14:12:10 <bjdmeest> ivan: we could be a little more explicit, but it's more theoretical
14:12:33 <bjdmeest> Topic: #10
14:12:37 <bjdmeest> https://github.com/w3c/dpub-pwp-loc/issues/10
14:13:32 <rdeltour> rdeltour has joined #dpub-loc
14:13:49 <rdeltour> present+ Romain
14:13:53 <bjdmeest> ivan: currently, the document says the complete PWP consists L and Lu and Lp
14:14:14 <bjdmeest> lrosenth: we weren't going to talk about the content of the M
14:14:23 <bjdmeest> ivan: we don't say anything more than about the locators
14:15:06 <bjdmeest> ... state-dependent locators are e.g., Lu and Lp, locators to unpacked and packed version
14:15:20 <bjdmeest> lrosenth: how can that remain state during the lifetime of PWP?
14:15:37 <bjdmeest> ... when I create a PWP, I assume my PWP has a manifest
14:15:43 <bjdmeest> ... once built, it cannot change
14:16:00 <bjdmeest> ... there may be extra Ms
14:16:11 <bjdmeest> ... but you cannot change the initial M
14:16:30 <bjdmeest> ... the locator in the initial M is the locator of the original source
14:17:01 <bjdmeest> ivan: when the PWP processor gets the full PWP manifest (maybe from different places)
14:17:22 <bjdmeest> ... in that manifest, there are the different locators, and the canonical locator
14:17:46 <bjdmeest> lrosenth: so definition is about final manifest
14:17:50 <bjdmeest> ivan: yes
14:18:15 <bjdmeest> ivan: so it is already in the draft
14:18:27 <bjdmeest> bjdmeest: great, let's close 10
14:18:35 <bjdmeest> Topic: manifest algorithm
14:19:09 <bjdmeest> http://w3c.github.io/dpub-pwp-loc/#algorithm-to-find-the-right-values-for-lp-and-lu
14:21:01 <bjdmeest> https://github.com/w3c/dpub-pwp-loc/pull/24
14:21:41 <bjdmeest> about issue #21
14:22:18 <bjdmeest> ivan: the original intro of the algorithm stated that it gets the manifest, as a consequence, it retrieves L*
14:22:27 <bjdmeest> ... I re-edited that part
14:22:27 <ivan> https://github.com/w3c/dpub-pwp-loc/pull/24/files
14:25:22 <bjdmeest> rdeltour: this is about finding the manifest, if final spec says that L == Lu, then we already know Lu, so part of the algorithm would be pruned?
14:25:30 <bjdmeest> ... we don't say nor exclude
14:25:48 <bjdmeest> ... I'm not sure it's a common use case to know both Lp and Lu
14:25:53 <bjdmeest> lrosenth: it's not
14:26:06 <bjdmeest> rdeltour: so why talk about it?
14:26:13 <bjdmeest> lrosenth: you need to get one of them
14:26:53 <bjdmeest> rdeltour: if it's an OR, given that in some cases you get Lu because L == Lu, then you don't need this algorithm
14:27:02 <bjdmeest> ivan: the PWP cannot make this assumption
14:27:25 <bjdmeest> ... the final spec might be very restricted
14:27:41 <bjdmeest> ... that changes things, but I would be very much against such a restriction
14:28:03 <bjdmeest> ... so currently, the PWP processor cannot assume such a restriction
14:28:31 <bjdmeest> rdeltour: given we already need the manifest, then let's talk about this section as 'getting the manifest'
14:28:49 <bjdmeest> ivan: in a general doc, you are probably right, but right now we are talking about the locators
14:29:17 <bjdmeest> rdeltour: but the manifest might have other information about the relative locators, so this is not just about Lu and Lp
14:30:01 <bjdmeest> ivan: this is highly editorial, at some point there is a more general discussion about what to do with this document
14:30:42 <bjdmeest> ... in such a general document, the section of dpub-loc would probably be moved to the general document
14:31:01 <bjdmeest> ... atm, we are not at that level yet
14:31:18 <bjdmeest> ... that's why I made the goal of this section: finding L/Lu/Lp via finding the manifest
14:31:54 <bjdmeest> rdeltour: I think as soon we talk about internal resources, then we need to get back at the manifest, and need that section as well
14:32:14 <bjdmeest> ... so why hide that this section is about fetching the manifest?
14:32:38 <bjdmeest> lrosenth: so let's change the title
14:33:08 <bjdmeest> ivan: fine, I will move this section as a top-level section
14:33:16 <bjdmeest> ... later, we can see how this evolves
14:33:56 <bjdmeest> ivan: so this is about: what kind of document will we end up with? this is not just locators
14:34:03 <bjdmeest> ... but happy to make the change
14:34:40 <bjdmeest> https://github.com/w3c/dpub-pwp-loc/pull/25/files
14:35:11 <bjdmeest> rrsagent, pointer?
14:35:11 <RRSAgent> See http://www.w3.org/2016/03/16-dpub-loc-irc#T14-35-11
14:36:36 <bjdmeest> ivan: added a note about remaining silent about retrieving a manifest from a package
14:38:50 <bjdmeest> rdeltour: that's ok, but comment about package being a black box... in the note, for some part of it, we go into very technical details (e.g., for html)
14:39:07 <bjdmeest> ... but we don't for package.. it makes the whole thing detailed/non-detailed
14:39:20 <bjdmeest> ... maybe large parts of the algorithm may be pruned
14:39:45 <bjdmeest> ... I see the algorithm more as an example of a complex situation
14:40:03 <bjdmeest> ... I think the note should be short and make general statements
14:40:20 <bjdmeest> ivan: this is similar as before: we don't know where this document will go
14:40:52 <bjdmeest> ... the only thing we do, is collect inputs, that would be input into a WG, that standardizes PWP
14:41:03 <bjdmeest> ... and all documents would need to be properly redone
14:41:35 <bjdmeest> ... atm, we have a good idea, so documenting as precise as we can, that's helpful for future WG
14:42:02 <bjdmeest> ... e.g., terminology discussion, that can change by a WG, but we documented that
14:42:36 <bjdmeest> ... we came up with this rough idea about how things could be done
14:42:56 <bjdmeest> ... and we wrote it down properly
14:43:06 <bjdmeest> rdeltour: I think it's great to have it
14:43:41 <bjdmeest> ... but I have a problem with the complexity on the one hand and the vagueness on the other hand
14:44:13 <bjdmeest> ... I would feel a short list of general statements would help
14:44:30 <bjdmeest> ... also, the entire section sounds like we nailed it, and have a formal spec
14:44:39 <bjdmeest> ... but there are still unresolved things
14:44:54 <bjdmeest> ... so: 1) perceived complexity, 2) perceived finality
14:46:01 <bjdmeest> bjdmeest: so we need a better intro? adding those short statements, that this is not final, etc.
14:46:14 <bjdmeest> ivan: that will be done because it will be separate section
14:46:49 <bjdmeest> ... I would merge the pull requests, and another round of editing, and then look at the results
14:47:42 <bjdmeest> ivan: [about the complexity] eventually, a bunch of details will be described in the same level of complexity
14:47:57 <bjdmeest> lrosenth: in order to accomplish all of the goals, it is the reality
14:48:44 <bjdmeest> rdeltour: so final specification could only provide some alternatives
14:49:01 <bjdmeest> ivan: if you look at the EPUB discussion..
14:49:28 <bjdmeest> rdeltour: depending on the eventual spec, the algorithm might be simpler
14:49:32 <bjdmeest> lrosenth: or more complex
14:51:16 <bjdmeest> ... all depends on the eventual implementation
14:51:26 <bjdmeest> https://github.com/w3c/dpub-pwp-loc/pull/26
14:51:30 <bjdmeest> rssagent, pointer?
14:51:39 <bjdmeest> rrsagent, pointer?
14:51:39 <RRSAgent> See http://www.w3.org/2016/03/16-dpub-loc-irc#T14-51-39
14:51:39 <rdeltour> +1
14:52:27 <bjdmeest> Topic #6
14:52:28 <bjdmeest> closed
14:53:00 <bjdmeest> Topic #11
14:53:04 <bjdmeest> https://github.com/w3c/dpub-pwp-loc/issues/11
14:54:04 <bjdmeest> lrosenth: same as what happens when you download a PWP
14:54:41 <bjdmeest> rdeltour: when you have a PWP online and download it, you have the canonical, dereferencable locator
14:55:00 <bjdmeest> ... if I have created a PWP locally, I don't have a canonical locator
14:56:04 <bjdmeest> lrosenth: you might have, because if the PWP must include L, every created PWP will have a L, but L might not be dereferencable
14:56:50 <bjdmeest> lrosenth: there is no requirement that the uri of a XML namespace must be dereferenced, maybe the same could go for locators of PWP
14:57:22 <bjdmeest> rdeltour: but we always talked about URLs, not URIs
14:57:39 <bjdmeest> lrosenth: if we only have a email-distributed PWP, and only read locally
14:57:43 <bjdmeest> ... it should still work
14:57:59 <bjdmeest> ivan: I would still like to have a clearer use case
14:58:12 <rdeltour> +1 on the need for a UC
14:58:31 <bjdmeest> ... an HTML send around by e-mail... that HTML file is not on the web
14:58:39 <bjdmeest> lrosenth: do PWP has to be on the web?
14:58:48 <bjdmeest> ivan: I don't know
14:59:15 <bjdmeest> lrosenth: UC: before I'm ready to publish it
14:59:34 <bjdmeest> ... during the authoring process, I create drafts, and send PWPs via emails to reviewers
14:59:53 <bjdmeest> ... so it doesn't exist on the web, but is built as a PWP
15:00:35 <bjdmeest> ivan: so your reviewer will receive you book, on local filesystem (file:///home/book.pwp), and thus has a locator
15:00:51 <bjdmeest> lrosenth: so different locators
15:01:43 <bjdmeest> ... so not necessarily in the file, but in the combined manifest
15:01:46 <bjdmeest> ivan: we need more concrete use caess
15:02:27 <bjdmeest> rdeltour: kind of included in portability buckets
15:03:30 <bjdmeest> ivan: next week, i might have to skip
15:03:41 <bjdmeest> rrsagent, pointer?
15:03:41 <RRSAgent> See http://www.w3.org/2016/03/16-dpub-loc-irc#T15-03-41
15:03:52 <bjdmeest> rssagent, draft minutes
15:03:57 <bjdmeest> rrsagent, draft minutes
15:03:57 <RRSAgent> I have made the request to generate http://www.w3.org/2016/03/16-dpub-loc-minutes.html bjdmeest
16:26:01 <ivan> rrsagent, set draft public
16:26:01 <RRSAgent> I'm logging. I don't understand 'set draft public', ivan.  Try /msg RRSAgent help
16:26:22 <ivan> rrsagent, set log public
16:26:28 <ivan> rrsagent, draft minutes
16:26:29 <RRSAgent> I have made the request to generate http://www.w3.org/2016/03/16-dpub-loc-minutes.html ivan
16:27:05 <ivan> Title: DPUB IG Locator TF call
16:27:09 <ivan> Chair: Ben
16:27:23 <ivan> Present+ Ivan
16:27:23 <ivan> rrsagent, draft minutes
16:27:23 <RRSAgent> I have made the request to generate http://www.w3.org/2016/03/16-dpub-loc-minutes.html ivan
18:34:13 <Zakim> Zakim has left #dpub-loc