W3C home > Mailing lists > Public > public-digipub-ig@w3.org > December 2016

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

From: Nick Ruffilo <nickruffilo@gmail.com>
Date: Mon, 12 Dec 2016 09:46:35 -0500
Message-ID: <CA+Dds5-6YoimvE_7E_427vNPPZY3PwF4hpKwxOM2EfGK2TZkCw@mail.gmail.com>
To: Leonard Rosenthol <lrosenth@adobe.com>
Cc: "DPUB mailing list (public-digipub-ig@w3.org)" <public-digipub-ig@w3.org>
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
Received on Monday, 12 December 2016 17:40:27 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:36:36 UTC