Bruno Dumon wrote:
On Wed, 2003-11-12 at 12:50, Berin Loritsch wrote:

Bruno Dumon wrote:

On Wed, 2003-11-12 at 12:19, Berin Loritsch wrote:


Instead I would highly encourage you to provide a way to set the base
URL where relative URLs would be resolved to.

Work *with* the contract instead of extending it in non-intuitive ways.

See my rant in another email.

Again see my rant in the other email. There are HUGE differnces in the way the URL is interpreted based on the existence of a repetitive character. It should be more obvious than that.


I somewhat agree with your rant, but I don't see the situation in Cocoon
changing any time soon since it would break backwards compatibility. I
find the cocoon:/ versus cocoon:// convenient to use though.

If I recall, I raised a hissy fit then too--I really don't like it.



BTW, there was a little error in your rant:
context://path/to/current/context/ should have been
context:///path/to/current/context/

See what I mean?


And yes, I find this to be even more troublesome.

Just how many forward slashes do you really need?


Ah, I wasn't clear enough: the three slashes are what you are asking
for, not what the situation currently is. According to the standard URL
path notation, the part after the first two slashes identifies the
authority (hostname usually). You see, seems like even the standard
isn't known well enough ;-) (or else I misunderstood the intend of your
remark)


The intent of the remark is to use a different standard than how many times the "/" character is used to differentiate between absolute and relative urls. It is a bug waiting to happen--and you won't hear much about it because everyone will be too embarrassed about the mistake.

THe secondary intent of the remark is to advocate a sort of xml:base="" (which
is a standard) to resolve relative URLs.

For example the path "foo/bar/baz.xml" can be resolved with a "context://" URL
if the xml:base is set with that in mind.  Alternatively, you can use
"cocoon://" or whatever.

It is more clear, as well as more flexible.




Reply via email to