DPUB IG Locator TF call

rssagent, pointer?

scribenick bjdmeest

https://github.com/w3c/dpub-pwp-loc/issues/9

Issue 9

ivan: about arbitrary resource within a packed PWP
... if no unpacked version, this will give a 404

lrosenth: given the server cannot process the packed PWP

ivan: this proposal is algorithmically ok
... but not realistic to set up

lrosenth: or the server could dynamically return the resource

ivan: then you wouldn't get a 404

lrosent: so you need a PWP-aware server

ivan: could be done via .htaccess

lrosenth: it is possible

ivan: viable, but not realistic

bjdmeest: so nothing more than a 404?

ivan: we could be a little more explicit, but it's more theoretical

#10

https://github.com/w3c/dpub-pwp-loc/issues/10

ivan: currently, the document says the complete PWP consists L and Lu and Lp

lrosenth: we weren't going to talk about the content of the M

ivan: we don't say anything more than about the locators
... state-dependent locators are e.g., Lu and Lp, locators to unpacked and packed version

lrosenth: how can that remain state during the lifetime of PWP?
... when I create a PWP, I assume my PWP has a manifest
... once built, it cannot change
... there may be extra Ms
... but you cannot change the initial M
... the locator in the initial M is the locator of the original source

ivan: when the PWP processor gets the full PWP manifest (maybe from different places)
... in that manifest, there are the different locators, and the canonical locator

lrosenth: so definition is about final manifest

ivan: yes
... so it is already in the draft

bjdmeest: great, let's close 10

manifest algorithm

http://w3c.github.io/dpub-pwp-loc/#algorithm-to-find-the-right-values-for-lp-and-lu

https://github.com/w3c/dpub-pwp-loc/pull/24

about issue #21

ivan: the original intro of the algorithm stated that it gets the manifest, as a consequence, it retrieves L*
... I re-edited that part

<ivan> https://github.com/w3c/dpub-pwp-loc/pull/24/files

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?
... we don't say nor exclude
... I'm not sure it's a common use case to know both Lp and Lu

lrosenth: it's not

rdeltour: so why talk about it?

lrosenth: you need to get one of them

rdeltour: if it's an OR, given that in some cases you get Lu because L == Lu, then you don't need this algorithm

ivan: the PWP cannot make this assumption
... the final spec might be very restricted
... that changes things, but I would be very much against such a restriction
... so currently, the PWP processor cannot assume such a restriction

rdeltour: given we already need the manifest, then let's talk about this section as 'getting the manifest'

ivan: in a general doc, you are probably right, but right now we are talking about the locators

rdeltour: but the manifest might have other information about the relative locators, so this is not just about Lu and Lp

ivan: this is highly editorial, at some point there is a more general discussion about what to do with this document
... in such a general document, the section of dpub-loc would probably be moved to the general document
... atm, we are not at that level yet
... that's why I made the goal of this section: finding L/Lu/Lp via finding the manifest

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
... so why hide that this section is about fetching the manifest?

lrosenth: so let's change the title

ivan: fine, I will move this section as a top-level section
... later, we can see how this evolves
... so this is about: what kind of document will we end up with? this is not just locators
... but happy to make the change

https://github.com/w3c/dpub-pwp-loc/pull/25/files

ivan: added a note about remaining silent about retrieving a manifest from a package

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)
... but we don't for package.. it makes the whole thing detailed/non-detailed
... maybe large parts of the algorithm may be pruned
... I see the algorithm more as an example of a complex situation
... I think the note should be short and make general statements

ivan: this is similar as before: we don't know where this document will go
... the only thing we do, is collect inputs, that would be input into a WG, that standardizes PWP
... and all documents would need to be properly redone
... atm, we have a good idea, so documenting as precise as we can, that's helpful for future WG
... e.g., terminology discussion, that can change by a WG, but we documented that
... we came up with this rough idea about how things could be done
... and we wrote it down properly

rdeltour: I think it's great to have it
... but I have a problem with the complexity on the one hand and the vagueness on the other hand
... I would feel a short list of general statements would help
... also, the entire section sounds like we nailed it, and have a formal spec
... but there are still unresolved things
... so: 1) perceived complexity, 2) perceived finality

bjdmeest: so we need a better intro? adding those short statements, that this is not final, etc.

ivan: that will be done because it will be separate section
... I would merge the pull requests, and another round of editing, and then look at the results
... [about the complexity] eventually, a bunch of details will be described in the same level of complexity

lrosenth: in order to accomplish all of the goals, it is the reality

rdeltour: so final specification could only provide some alternatives

ivan: if you look at the EPUB discussion..

rdeltour: depending on the eventual spec, the algorithm might be simpler

lrosenth: or more complex
... all depends on the eventual implementation

https://github.com/w3c/dpub-pwp-loc/pull/26

rssagent, pointer?

<rdeltour> +1

Topic #6

<scribe> closed

Topic #11

https://github.com/w3c/dpub-pwp-loc/issues/11

lrosenth: same as what happens when you download a PWP

rdeltour: when you have a PWP online and download it, you have the canonical, dereferencable locator
... if I have created a PWP locally, I don't have a canonical locator

lrosenth: you might have, because if the PWP must include L, every created PWP will have a L, but L might not be dereferencable
... there is no requirement that the uri of a XML namespace must be dereferenced, maybe the same could go for locators of PWP

rdeltour: but we always talked about URLs, not URIs

lrosenth: if we only have a email-distributed PWP, and only read locally
... it should still work

ivan: I would still like to have a clearer use case

<rdeltour> +1 on the need for a UC

ivan: an HTML send around by e-mail... that HTML file is not on the web

lrosenth: do PWP has to be on the web?

ivan: I don't know

lrosenth: UC: before I'm ready to publish it
... during the authoring process, I create drafts, and send PWPs via emails to reviewers
... so it doesn't exist on the web, but is built as a PWP

ivan: so your reviewer will receive you book, on local filesystem (file:///home/book.pwp), and thus has a locator

lrosenth: so different locators
... so not necessarily in the file, but in the combined manifest

ivan: we need more concrete use caess

rdeltour: kind of included in portability buckets

ivan: next week, i might have to skip

rssagent, draft minutes

<ivan> Title: DPUB IG Locator TF call