forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nicola Ken Barozzi <>
Subject Re: File prefix again (Re: Cocoon CLI - how to generate the whole site)
Date Mon, 16 Dec 2002 15:08:37 GMT

Jeff Turner wrote:
> On Mon, Dec 16, 2002 at 02:01:52PM +0100, Nicola Ken Barozzi wrote:
>>Jeff Turner wrote:

>>>The file: patch has two effects:
>>>- Introduce schemes in xdocs, starting with a 'file:' scheme.  I think
>>>  that schemes in general are uncontroversial.  When linkmaps arrive,
>>>  90% of links are going to be linkmap links, so having a scheme prefix
>>>  should be the norm. 
>>I'm totally for the scheme concept. But schemes are IMHV onlt link 
>>rewriting rules, and should not address other concerns.
>>A file: scheme would not do any rewriting, so I don't see the need ATM.
> ...
>>>What we really need to agree on is the first point; whether we want to
>>>prefix static links with 'file:'.  When xdocs are swarming with linkmap:,
>>>java:, person:, mail:, etc links, why not have file:?  Conversely, if we
>>>want to "infer" the file: scheme, are we going to try to infer all the
>>>other schemes?
>>Hmmm, I don't see the big problem here, but I may as well be wrong.
>>The schemes are link-rewriting systems.
> Schemes are what the URI RFC defines them to be:
>   "The URI scheme (Section 3.1) defines the namespace of the URI, and
>   thus may further restrict the syntax and semantics of identifiers using
>   that scheme.

Corrected: Forrest schemes IMV are link-rewriting systems. This is to 
make the resulting URI space be completely decoupled from the source space.

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

First distinction: schemes are not IMV in the source URI space, but in 
the destination URI space, hence my definition of link rewriting. Links 
are always seen from the outside IMV. With this in mind, you can infer 
why I don't see the need for a file: scheme.

Thus I link to the resulting URI space, not the source one. The 
resulting URI space can be complicated, so to ease the linking I use 
schemes to make linking easier.

Well, it might as well be not the best thing to do, but this is what 
I've been saying till now, so I see why we didn't really understand each 

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

I read it, and I basically agree with it, except the above distinction 
which wasn't clear to me in the first place.

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

Please expand on this. Do you mean file scheme=sources and cocoon 
scheme=resulting URI space?

> Practically, right now, what is the difference?
> Well for a start, if we consistently used 'file:' for URIs identifying
> static files, we could throw away the current resource-exists action:
>   <map:match pattern="**">
>     <map:act type="resource-exists">
>      <map:parameter name="url" value="content/{1}"/>
>      <map:read src="content/{../1}"/>
>     </map:act>
>     ....
> And replace it with a simple sitemap rule:
>   <map:match pattern="file:**">
>     <map:read src="content/{1}"/>
>   </map:match>

Which is something I don't like.

Again, you are telling Cocoon how to treat that file, which is not a 
concern of the editor.

We decided to take away the extension to files, but this file: thing 
does the same conceptual thing, it selects the sitemap to use inside the 

> Having to interrogate the filesystem to decide a URI's scheme is a total hack.
> What happens if our docs are stored in Xindice, or anything other than a
> filesystem?  Resource-exists is going to break.

Hmmm, this is a good point, but not a resource-exists "conceptual" 
problem. I can test if a resource exists also in remote repositories.
If the "file:" thing takes care different backends, there is no reason 
why a better resource-exists cannot. So seems is more about the 
deficiencies of the resource-exists implementation rather than the need 
of a site: scheme.

> Secondly, introducing a 'file:' prefix fixes the current name clash problem.
> What if I have a static file called 'index.pdf'?  How do I access the index.pdf
> generated from XML?  I can't, because the resource-exists will always choose
> for me.

Which is another seemingly good point, but since we have decided that 
link URIs should not end in extensions, because of many reasons one of 
which is the fact that a URI can reference different formats at 
different times in history, having a scheme that effectively makes me 
serve two different versions of the same file is totally off-target.

> So there are two practical reasons, and a bunch of theory, as to why we should
> have a 'file:' prefix.

Nicola Ken Barozzi         
             - verba volant, scripta manent -
    (discussions get forgotten, just code remains)

View raw message