Stefano Mazzocchi wrote:
<snip/>
The only potential solution I see is something like
<generate src="cocoon:/path" xml:base="/"> <generate src="cocoon:/path" xml:base=".">
I think that would not be correct usage of the xml:base... Correct usage would be something like:
<generate src="path" xml:base="cocoon:/">
<generate src="path" xml:base="cocoon:"> <!-- or xml:base="cocoon:." -->
<snip/>
Wouldn't it be much more common to do something like this:
<pipelines xml:base="cocoon:">
<pipeline>
<match uri="**/foo">
<generate src="path"/>
<transform src="path"/>
<serialize/>
</match>
<match uri="**/bar" xml:base="context:/foo/bar">
<generate src="path"/>
<transform src="path"/>
<serialize/>
</match>
</pipeline>
</pipelines>In other words, the xml:base attribute (according to spec) applies the the URLs contained in the element it is declared in, as well as to all child elements--unless a child element overrides it.
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?
Any of the above does not look neither elegant nor easier. I'd keep the approach we have right now.
Just because we have one protocol that is messed up and we can't change it doesn't mean we should make the same mistakes.
For the Context protocol, I highly recommend doing something other than the one slash vs. two approach used for the "cocoon" protocol.
*Something* doesn't have to mean using the xml:base approach outlined above. But it does mean that we shouldn't repeat the same mistake.
