forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeff Turner <>
Subject Re: File prefix again (Re: Cocoon CLI - how to generate the whole site)
Date Wed, 18 Dec 2002 15:45:07 GMT
On Thu, Dec 19, 2002 at 02:17:40AM +1100, Jeff Turner wrote:
> Popping the argument stack a bit, remember that this whole silly example
> of index.xml/index.pdf is a pathological case, that won't have the
> desired effect no matter what the URI is.  You have ignored my main
> argument, that the 'cocoon:' prefix is implicit and _conceptually_ a
> file: scheme is required.

For your convenience, here is the conceptual justification for 'file:',
11 emails ago:

> Why would we need to rewrite "file:"s?

Given the above definition, what do you think the implied scheme for
<link href="hello.pdf"> is?  What syntactic and semantic restrictions are
there?  Can we link to anything?  No: we can only link to URIs defined by
sitemap rules.  Therefore the implied scheme is 'cocoon:'.  I need to
invoke Cocoon to get 'hello.pdf'.  If my editor were written in Java as
an Avalon component, it might really be able to invoke Cocoon and
retrieve 'hello.pdf'.

What about when a file is sitting on my harddisk?  Do I need Cocoon to
view it?  No; I can open it in an editor.  Hence the 'file:' protocol is
implied.  In fact, in vim I can type 'gf' and automatically traverse the
link.  My editor is a 'browser' of the Source URI space, just like
Mozilla browses the Destination URI space.

That is the important concept: the Source URI space is distinct from the
Destination URI space.  In the Source URI space (XML docs + <link>
elems), we have all sorts of schemes (linkmap:, java:, file:, person:
etc), but in the Destination URI space (HTML docs + <a> elems), we have
only one protocol, usually http: or file:.

I described this notion of separating the Source and Destination URI
space in a RT:

So that is the theory: it is better to have an explicit file: scheme,
because it distinguishes those URIs from the implied 'cocoon:' scheme,
and fits in better in a world where there are schemes everywhere.


To that, your response started:

> First distinction: schemes are not IMV in the source URI space, but in
> the destination URI space

In the intervening 11 emails, I hope I have at least convinced you of the
wrongness of that statement, and hence the position you held back then,
based on it.


View raw message