Re: Thoughts/re-write on 2.2.2 Canonical Locators Mapping in user agents

> On 12 Jan 2017, at 17:48, Nick Ruffilo <nickruffilo@gmail.com <mailto:nickruffilo@gmail.com>> wrote:
> 
> Here are my original comments.  For the locators section : http://w3c.github.io/dpub-pwp/#locator-pwp-func <http://w3c.github.io/dpub-pwp/#locator-pwp-func>
> 
> Unless I'm misunderstanding this section, the goal of a locator is to be able to point to a specific resource, and optionally to a specific point within that resource.  I believe this can all be done very simply without mentioning state, or at least without requiring that anything different happen.
> 
> I honestly think we can boil the whole section down by saying:
> 
> "Every resource within a PWP should be accessible given that that root of the PWP is its current location or state.  For example, the image '/images/cover.png' in a PWP located at http://example.org/mypwp <http://example.org/mypwp> would be accessible at http://example.org/mypwp/images/cover.png <http://example.org/mypwp/images/cover.png> and a PWP that is packaged and on a file system should be accessible via mypwp.pwp/images/cover.png.
> 
> Locators pointing to content within a resource would be appended as they are today using # or ? after the file name and whatever location method."
> 
> Am I missing something?  Is there a use case that this does not cover?
> 

Well… The problem is with the exact way of referring to a publication (essential points in many disciplines). If the same work, having the same ISBN (or equivalent) is positioned at:

http://publishers-official-website.com/wonderfulwork.pwp <http://publishers-official-website.com/wonderfulwork.pwp>

Then both you and I have purchased/acquired a copy, then we may have

http://www.nick-ruffilo.net/wonderfulwork.pwp <http://www.nick-ruffilo.net/wonderfulwork.pwp>
http://www.ivan-herman.net/wonderfulwork.pwp <http://www.ivan-herman.net/wonderfulwork.pwp>

And then Tzviya writes a text where she wants to refer to a particular paragraph to the book, but she read my copy, what URL would she use for an authoritative reference? How would she find that? Same kinds of questions with annotations added to the document: where would an annotation point to?

We have these here:

http://w3c.github.io/dpub-pwp-ucr/#unique-identifier <http://w3c.github.io/dpub-pwp-ucr/#unique-identifier>
http://w3c.github.io/dpub-pwp-ucr/#identify_const_resources <http://w3c.github.io/dpub-pwp-ucr/#identify_const_resources>

We may not have a 100% satisfactory answer and it may be a matter of good practices. But documenting those may still be relevant.

B.t.w. (you were asking this on the call): where a manifest-like-thing may come into the picture is to have an agree-upon place to store http://publishers-official-website.com/wonderfulwork.pwp <http://publishers-official-website.com/wonderfulwork.pwp>. And it may be the only thing we have to say here, but there may also be other issues.

Thanks

Ivan

> -Nick
> 
> 
> On Mon, Dec 12, 2016 at 9:46 AM, Nick Ruffilo <nickruffilo@gmail.com <mailto:nickruffilo@gmail.com>> wrote:
> Leonard,
> 
> My apologies that we could not schedule a good time to co-ordinate.  I know you did some work on this, and hopefully my notes below can help with this.
> 
> After a few read throughs, I've realized a few things:
> 
> 1) Does state really matter?  Ultimately, any resource within a PWP should be findable using: (PACKAGE_LOCATION)/(RESOURCE LOCATION)
> Doesn't matter if its http://example.org/book/1 <http://example.org/book/1> as the package_location or package.zip on a file system.
> 
> 2) As long as the package never uses / as the root of the package, nothing should explode.  All items within a PWP should reference things relatively and there will be no conflicts (although, i could see an argument where, within a PWP, you use / to mean the root of the package, but that seems to go against the core of what already works on the web)
> 
> 3) If #1 is true, the only change to an existing user agent from what happens today is that if a file is not found, it's successive roots should be checked.
> 
> For example if you have: http://example.org/book.zip/images/small/myimage.jpg <http://example.org/book.zip/images/small/myimage.jpg> the user agent would need to first check http://example.org/book.zip/images/small/myimage.jpg <http://example.org/book.zip/images/small/myimage.jpg>, then http://example.org/book.zip/images/small/ <http://example.org/book.zip/images/small/> then http://example.org/book.zip/images <http://example.org/book.zip/images> then http://example.org/book.zip <http://example.org/book.zip> at which point it would try to - from that archive - extract the full path.
> 
> No reference to a manifest is required.
> 
> If not complete by today, I will work with Leonard to incorporate this into a cleaner section for this.
> 
> Thank you
> 
> --
> - Nick Ruffilo
> @NickRuffilo
> Aer.io <http://aer.io/> an INGRAM company
> 
> 
> 
> 
> --
> - Nick Ruffilo
> @NickRuffilo
> Aer.io <http://aer.io/> an INGRAM company
> 


----
Ivan Herman, W3C
Digital Publishing Technical Lead
Home: http://www.w3.org/People/Ivan/ <http://www.w3.org/People/Ivan/>
mobile: +31-641044153
ORCID ID: http://orcid.org/0000-0003-0782-2704 <http://orcid.org/0000-0003-0782-2704>