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.
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.
Using an URIs like the ones above has the advantage that we can reuse most of the definition of hierarchial URIs and the functionality in java.net.URI, if we instead go for the opaque style exemplified by "block:super://blah.xml" we have to define the URI parsing ourselves instead.
--- o0o ---
As all URI discussions tend to provoke strong feelings for Stefano, it's best to say directly that this question is not important enough for me to fight about ;)
But anyway, whether we go for an opaque custom protocol or base the block protocol on hierachial URIs we need to get into the specifics for the block URI scheme to be able to implement it.
WDYT?
/Daniel
