Mailing-List: contact cocoon-dev-help@xml.apache.org; run by ezmlm
Sender: niclas@envision.asiaconnect.com.my
Message-ID: <38E2B656.48D16F7@localbar.com>
Date: Thu, 30 Mar 2000 10:05:11 +0800
From: Niclas Hedhman <niclas@localbar.com>
Organization: Bali Automation Sdn Bhd
MIME-Version: 1.0
To: cocoon-dev@xml.apache.org
Subject: Re: [RT] latest wonderings around W3C land and surroundings
References: <NCBBKKMPILBOFACAPHDDMEOMEBAA.gerard.van.enk@eo.nl>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Gerard van Enk wrote:

> > ----------- XBase ----------------
> > think about it: if you have xbase:base="http://myhost/mypath/" in your
> > document, how are you going to move it around?
> > Hmmm, makes me think that XBase is good on client side, but on server
> > side sucks.
> >
> I agree, but in the future it will be used, also on the server side..
> > ------------- XInclude -------------
> > ----------- XLink -----------------
> > The question is: how do we perform such transformation? Should there be
> > a sort of "stylesheet" for links? should this information be contained
> > in the sitemap? if so, how?
>
> > and even more important: is the idea of "soft" links good as it sounds
> > appealing? or hides trouble by adding another abstraction to remove the
> > URI-space contracts between site management and document writers? Should
> > those URI contracts be enforced rather than weaken up like this?
>
> How can a person who didn't write the document, take care of the link
> translation?

These are all related to the "context-separation-dilemma".
We can all agree that any public document should not be moved in URI space,
ever. But does this also extend to internal URIs??  I believe this is the core
of the question. If the answer is YES, then the content writer could/should be
"granted" these resources. If the answer is NO, these issues are evil.

I tend to have different oppinions about this every day, but I seem to stablize
on YES, since I believe (now!) that Cocoon and other technologies will ease the
Site managers problems of maintaining the URI space.

So any links or references through the local URI space must be translated in
the SiteMap, and global links/refs must be requested over the global protocols.

The local URI translation is also tricky;
/abc/def/ghi/jkl
doesn't necessarily match the entry
<process uri="abc/**" source="/mysite/abc/**">

since /abc/def/ could be part of the servlet resolution.
So, we are then in the position that Cocoon needs to know its own URI mapping,
either for the purpose of resolving the above, and/or to make global requests
for resources outside its own scope. (Or be able to call JServ/Apache back,
which I believe is not possible.)

(Makes me feel that all this belong in the Webserver/Servlet engine. )

Niclas