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...
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.
The only problem I have with "block:super://blah.xml" is that "//" in an URI indicates the start of the authority part, and this is defined as "[EMAIL PROTECTED]:port", and no matter how you see it, "block:...anything..." _is_ a URI, and thus should follow its spec...
Pier
--- 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
smime.p7s
Description: S/MIME cryptographic signature
