forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeff Turner <>
Subject Re: file: implemented (Re: cvs commit: ...)
Date Wed, 11 Dec 2002 09:35:47 GMT
On Wed, Dec 11, 2002 at 12:32:01AM +0100, Nicola Ken Barozzi wrote:
> I think you jumped a bit too quickly on this, I'm -1 on it.


> It really looks like a big hack to get round an issue we still have to
> finish discussing.

Well it's all clear in _my_ head.. isn't that enough?  sheesh.. ;P

> I really don't like it, and would have preferred you wait a bit more
> before committing it.

Lazy consensus and all..

Actually, I just wanted to solve the "can't link to external file"
problem, but the implementation implies a larger design choice, so I've
reverted it.

> Sorry if I'm a bit strong on it, but it creates more confusion and 
> convolution.
> If we make links not be traversed in the definition,

Who suggested that?  All links are traversed _except_ for those with
specific schemes like 'file:' or 'javadoc:', which are handled specially.
That is why I said the implied scheme is 'cocoon:'.

> we are opening wide a door to abuse and failing of link checking.

Actually with the current implementation, we can do _more_ link checking.
Eg, we can record http: links (without rewriting them), and then later in, check if they really exist.

> My proposed solution is to
> 1) make Cocoon use resource-exists to see if it has to process it or not

We already have a resource-exists check.  The problem is that the CLI
adds a '.html' to the URLs of static resource, because it doesn't know
that they are static.  To fix this, the CLI would need access to the
xlink:role attribute.  Every new scheme would require a Cocoon CLI hack.

If we're going to have a proliferation of schemes, like 'site:',
'person:', 'javadoc:', 'mailinglist:', etc etc, doesn't it make sense to
have 'file:' as well?  And deal with all of them in Forrest's sitemap,
rather than the Cocoon CLI?  For instance, we _could_ hack the CLI to
ignore links starting with 'javadoc:', but isn't it easier to prevent
them being passed to Cocoon in the first place?  Then all support for the
'javadoc:' scheme is within Forrest XSLTs.

> 2) if it has to process it, use CAPs to understand how
> 3) have the possibility of "mounting" documents from outside, ie if I 
> mount the /my/javadocs to the javadocs: protocol, I link to 
> "javadocs:index.html" and it gets resolved to the correct path.

Yes.  I could implement javadocs: in half an hour if we can agree on
where to obtain '/my/javadocs/' from.


View raw message