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

Here are my original comments.  For the locators section :
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 would be
accessible at 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?

-Nick


On Mon, Dec 12, 2016 at 9:46 AM, Nick Ruffilo <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 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 an *INGRAM* company
>
>


-- 
- Nick Ruffilo
@NickRuffilo
Aer.io an *INGRAM* company