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

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 <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