forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeff Turner <>
Subject File prefix again (Re: Cocoon CLI - how to generate the whole site)
Date Mon, 16 Dec 2002 14:20:17 GMT
On Mon, Dec 16, 2002 at 02:01:52PM +0100, Nicola Ken Barozzi wrote:
> Jeff Turner wrote:
> >On Mon, Dec 16, 2002 at 08:59:32AM +0100, Nicola Ken Barozzi wrote:
> >
> >>Jeff Turner wrote:
> >
> >...
> >
> >>>>We've established that Cocoon is not going to be invoking Javadoc.  That
> >>>>means that the user could generate the Javadocs _after_ they generate

> >>>>the
> >>>>Cocoon docs.
> >>>>
> >>>>To handle this possibility, the only course of action is to ignore links
> >>>>to external directories like Javadocs.  What alternative is there?
> >>
> >>Yes, but I don't want this to happen, as I said in other mails.
> >>The fact is that for every URI sub-space we take away from Cocoon, we 
> >>should have something that manages it for Cocoon, and that's for *all* 
> >>the environments Cocoon has to offer, because Forrest is made to run in 
> >>all of them.
> >
> >
> >Ah, gotcha :)
> Pfew, it took a long time didn't it?


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

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

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}"/>

And replace it with a simple sitemap rule:

  <map:match pattern="file:**">
    <map:read src="content/{1}"/>

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.

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.

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


View raw message