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.
smime.p7s
Description: S/MIME cryptographic signature
