Pier Fumagalli wrote:
On 4 Apr 2005, at 16:26, Daniel Fagerstrom wrote:
Pier Fumagalli wrote:
On 31 Mar 2005, at 01:26, Stefano Mazzocchi wrote:
block:super://blah.xml
A very simple remark, I don't want to criticise...
I'm already slightly "upset" about the "cocoon://" protocol, as it does not follow the URI RFC properly, I'd like to address the problem as early as possible...
http://www.ietf.org/rfc/rfc2396.txt
I wrote a small "rant" while on the plane, just to explain my reasoning, with a couple of code examples, as it's (I don't think) mailing-list material, I've stored it on my WIKI...
http://www.betaversion.org/~pier/wiki/display/pier/Cocoon+and+URIs
Anyhow, feel free to discuss it here...
I read your rant and agree with it, it seem benefical to take advantage of java.net.URI. I'm not completely happy with letting relative sitemap paths be opaque and absolute be hierarchical, but I don't see any better alternatives.
The thing is that the scheme specific part of the opaque URI, is actually a relative URI which can be resolved against an absolute one...
URI relative_uri = absolute_uri.resolve(opaque_uri.getSchemeSpecificPart());
As simple as that...
Concerning:
block:super://blah.xml
it is AFAICS a correct opaque URI. But we could make better use of java.net.URI if we considered a hierarchial URI scheme for blocks instead. From this perspective the scheme that Reinhard suggested makes sense
block://portal/foo
for refering to the absoute path "/foo" within the portal block,
block:/foo
for refering to the absolute path "/foo" within the current block and
block:./bar
for refering to the relative path "bar" relative to the current (sub)sitemap within the current block and
block:super:/foo
for refering to the absolute path "foo" whithin the super block of the current and possibly
block:super:./bar
for refering to the relative path "bar" relative to the current (sub)sitemap within the super block of the current.
The last three URIs are opaque and could be resolved to absolute hierarchical URIs with a similar algorithm as you proposed for "cocoon:./" resolution.
Maybe using "//portal" as an authority is stretching the intepretation to far.
Exactly... That's why I'm thinking that the URI should be this:
block:portal:/foo
block is an opaque URI, whose scheme specific part _is_ a valid URI by itself.
portal:/foo is a valid URI, but if (for example) you think about other cases, this URI could be
block:xmlrpc://www.myrpcserver.dom/entry/point
block: opaque URI
xmlrpc: valid URI whose scheme specific part (whether it's opaque, absolute, relative, blah) is only known by the "xmlrpc" handler...
block:portal:/foo
What's "/foo"? Only the portal block knows it...
Ok, that makes sense. The specific blocks handler resolve the scheme specific part. If we follow this path the blocks descriptor (http://wiki.apache.org/cocoon/BlocksCob) must be extended with a declaration about what source resolver to use.
It would still be good to have a default resolver for all blocks that doesn't have specific needs, so that we get some coherence for our blocks. And there we could use hierarchical URIs like those you propsed in your wiki for the cocoon: protocol.
Question is how i.e. the portal block refers to its own pipes. If you take a look at http://wiki.apache.org/cocoon/BlocksCob a block doesn't have a short name for it self that can be used as scheme, it only declares such names for the blocks it requires, so portal: doesn't make any sense within the portal block. So within the specific block we could maybe use:
block:/foo, block:./bar, block:super:/foo, block:super:./bar
whith the same intepretation as I suggested above (for the default resolver).
This could be done in the way that each block define its own resolver and bind it to the scheme block:, then when a block, portal e.g. use an URI to another block, the block manager (for portal) will get an URI like:
block:skin:/foo
it will then find the block manager for the skin block and ask it to resolve
block:/foo
Which will use the resolver from the skin block.
/Daniel
