Re: [Locators] Musing on the "URL of a constituent resource" issue...

http://www.w3.org/Provider/Style/URI.html

:)


On Tue, Dec 22, 2015 at 9:26 AM, Ivan Herman <ivan@w3.org> wrote:
> Hi all,
>
> Just some musing on the whole 'what is the URL of a constituent resource'
> issue related to locators; I wanted to step away from the '#' vs. '!' issue.
> Sorry for a somewhat longer mail, bear with me; I have some specific
> questions at the end which may or may not direct us in a different
> direction...
>
> To begin, what is the use case which raises this whole discussion in the
> context of PWP?
>
> Let us say we have two PWP-s, 'A' and 'B'. They have each a URL, ie, a
> locator, say:
>
> • http://www.ex.org/A
> • http://www.ex.org/B
>
> The use case we referred to on the call is that there may be a shared
> resource 'F' that the publisher wants to maintain (say, a font file on its
> own location on the Web, say at:
>
> • http://fonts.ex.org/F
>
> Per the definition of a PWP, there is no reason why the resource 'F' would
> not be part of both 'A' and 'B'. After all, 'A' and 'B' are Web
> Publications, ie, "an aggregated set of interrelated Web Resources". Members
> of that set are "listed" somewhere to define 'A' and 'B', respectively; this
> is also why we would have a manifest (let us put the manifest format aside
> for now). If 'F' is self contained, then 'A' and 'B' are also portable web
> publications. So? Are we done, there is no issue, can we go home? :-)
>
> Well... I think that there are legitimate situations when we want to use
> that font from within 'A' or 'B', with simple, fixed, and probably relative
> URL-s. E.g., the publisher wants an easy way to relocate 'F' for whatever
> reasons to, say, http://fonts.ex.org/fonts/F; that may require all resources
> in, say, 'A' to change their URL-s to F. Not good. If there is one place 'X'
> that 'points' to the URL of 'F', and all resources 'A' refer to the URL
> representing 'X' then maintenance becomes easy. This is a case where our
> discussion comes into the picture (using, say, '!' or cfi or similar).
>
> Stepping away from the Web for a moment: the scenario above is actually
> fairly common in managing one's own file system. And this is why these crazy
> computer scientists invented symbolic links. This means that, in my folder
> (or directory, depending on the term used), I can create a symbolic link 's'
> that refers to the file 'f' somewhere on my file system. Any program
> referring to 's' (ie, reading the content 's') will in fact read,
> transparently, the content of 'f'; ie, the system will silently open 'f' for
> that content. If 'f' is moved then 's' has to change, but no other program
> has to be changed. Symbolic links are used all over the place; they have
> been around on UNIX-like systems (that includes OS X) for ages and, afaik,
> they are also available in Windows.
>
> Does this sound familiar? The melody is similar to our issue... Actually, on
> specific Web servers it is perfectly possible to reproduce something
> somewhat similar. Apache knows the 're-write rule' concept; on my server I
> can (if I have the right authorization) set up a special file (usually
> .htaccess) where I can add a rewrite rule which essentially says:
>
> • "if you see 'http://www.ex.org/A/fonts/F' then go to
> 'http://fonts.ex.org/F' instead"
>
> (What this really does is to send back an HTTP response to the client
> instructing it to issue a new request to the other URL.)
>
> The good think is that this is common occurence on the Web, and does not
> require any special processing on the client. The bad thing is that this is
> Apache specific, not all users have the right to set something like that up,
> not all users knows what exactly to do. But, also, it is a bit vulnerable
> because all re-write rules would be in one place (at least for a directory):
> the distributed approach of symbolic links is much safer against accidental
> damage, which is a good thing.
>
> So… here is my question. Is it possible to have a symbolic link like
> structure to solve our problems? I.e., tiny small files (possibly with some
> attached minor javascripts) whose only role is to instruct the client to do
> a redirection somewhere else? Something that makes use of existing
> technologies; ideally, the client (browser, javascript) should not even have
> to do anything because all the redirections are handled on HTTP level?  I
> have seen PHP based solutions, but that is not a good approach, we do not
> want to be dependent on a specific server side technology. Anybody knows a
> good approach that we may get inspired by?
>
> (Actually, if the server runs Linux (or MacOS) real symbolic links also make
> the trick, because servers would follow those just as any other programs
> do.)
>
> Is this line of thought worse pursuing, or is complete boloney?
>
> Merry Xmas or any other relevant holidays to you all!
>
> Ivan
>
>
>
>
> ----
> Ivan Herman, W3C
> Digital Publishing Lead
> Home: http://www.w3.org/People/Ivan/
> mobile: +31-641044153
> ORCID ID: http://orcid.org/0000-0003-0782-2704
>
>
>
>

Received on Wednesday, 23 December 2015 17:54:03 UTC