On 12 Nov 2003, at 17:18, Berin Loritsch wrote:
> Stefano Mazzocchi wrote:
>> Variable scoping aside, do you have any suggestion on how to solve
>> the protocol issue?
>> --
>> Stefano, who reached a point where rants look like a very inefficient
>> way of solving problems
>
> As I mentioned in another email, leverage the xml:base="" attribute
> part of
> the XML spec. That provides the base URI with which all relative URIs
> would
> be resolved. It's dead simple, obvious, and less error prone than one
> slash
> vs. two. Best of all, we don't bastardize any specs.
Now, we introduced the ** syntax for matchers and I think it was one of
the greatest innovations in easy-to-use path-oriented query syntaxes,
althought non standard. Nobody ever complained and I don't think it's
because they are too shy to tell us.
At the same time I agree that
cocoon:/blah
and
cocoon://blah
don't feel exactly as elegant. Actually
cocoon:foo/bar
and
cocoon:/blah/bar
would be better, IMO, but would be totally back-incompatible at this
point, so it's hard to change this syntax now.
The problem I see with your proposal is that xml:base doesn't really
solve anything: we need to be able to differentiate between
path -> relative to current sitemap
path -> relative to root sitemap
this discrimination has the granularity of the single cocoon:/context:
call, it's not global. The only potential solution I see is something
like
<generate src="cocoon:/path" xml:base="/">
<generate src="cocoon:/path" xml:base=".">
but I don't think xml:base works for this. An alternative is
<generate src="cocoon:/path" relative-to="/">
<generate src="cocoon:/path" relative-to=".">
which would allow to do
<pipeline relative-to="./path">
<match ...>
<generate src="cocoon:/blah"/>
...
that would be equivalent to what today is
<generate src="cocoon:/path/blah"/>
but I'm not sure this makes things any easier or bugs any more evident.
For sure, it's more verbose and for back compatibility, we still need
to support cocoon://
Thoughts?
--
Stefano.
|