Re: [RT] ComponentizedProcessor (was RE: Migrating TreeProcessor to Fortress)

[Bruno Dumon <br...@outerthought.org>]

On Wed, 2003-11-12 at 12:02, Berin Loritsch wrote:
> Sylvain Wallez wrote:
> > Unico Hommes wrote:
> > 
> >
> >> Wild idea: context:/ identifies the current context, context:// 
> >> identifies the root sitemap? Like in cocoon: protocol?
> >>  
> >>
> > 
> > Great idea (again!). Currently, the "context:" protocol requires the 
> > double-slash and links to the root sitemap, so we can implement this 
> > additional behaviour with a single slash with no compatibility break. 
> > And the similarity with "cocoon:" makes it easy to understand.
> > 
> > This makes me think that "cocoon:" must also be be relative to the 
> > "current" sitemap, and not that handling the request.
> 
> BAD IDEA.
> 
> Please, you are adding contracts to the URL spec that aren't there.

Not really true. The basic structure of an URL is:

<scheme>:<scheme-specific-part>

and the interpretation of the scheme specific part depends on the
scheme.

> 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.
-- 
Bruno Dumon                             http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
bruno@outerthought.org                          bruno@apache.org

Re: Bastardized URL protocol (was Re: [RT] ComponentizedProcessor)

[Berin Loritsch <bl...@apache.org>]

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.

Re: Bastardized URL protocol (was Re: [RT] ComponentizedProcessor)

[Bruno Dumon <br...@outerthought.org>]

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)

-- 
Bruno Dumon                             http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
bruno@outerthought.org                          bruno@apache.org

Bastardized URL protocol (was Re: [RT] ComponentizedProcessor)

[Berin Loritsch <bl...@apache.org>]

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?

> 
> 
>>And don't forget that URLs do have the concept of *resolving* relative
>>URLs.  THose are the contracts I am refering to.
> 
> 
> Yes, but it's still up to the scheme to specify if it follows those
> contracts or not.
> 

They are there, and well understood--is there a compelling reason *not*
to use them?

Re: [RT] ComponentizedProcessor (was RE: Migrating TreeProcessor to Fortress)

[Bruno Dumon <br...@outerthought.org>]

On Wed, 2003-11-12 at 12:19, Berin Loritsch wrote:
> Bruno Dumon wrote:
> > On Wed, 2003-11-12 at 12:02, Berin Loritsch wrote:
> > 
> >>Sylvain Wallez wrote:
> >>
> >>>Unico Hommes wrote:
> >>>
> >>>
> >>>
> >>>>Wild idea: context:/ identifies the current context, context:// 
> >>>>identifies the root sitemap? Like in cocoon: protocol?
> >>>> 
> >>>>
> >>>
> >>>Great idea (again!). Currently, the "context:" protocol requires the 
> >>>double-slash and links to the root sitemap, so we can implement this 
> >>>additional behaviour with a single slash with no compatibility break. 
> >>>And the similarity with "cocoon:" makes it easy to understand.
> >>>
> >>>This makes me think that "cocoon:" must also be be relative to the 
> >>>"current" sitemap, and not that handling the request.
> >>
> >>BAD IDEA.
> >>
> >>Please, you are adding contracts to the URL spec that aren't there.
> > 
> > 
> > Not really true. The basic structure of an URL is:
> > 
> > <scheme>:<scheme-specific-part>
> > 
> > and the interpretation of the scheme specific part depends on the
> > scheme.
> > 
> > 
> >>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.

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

> And don't forget that URLs do have the concept of *resolving* relative
> URLs.  THose are the contracts I am refering to.

Yes, but it's still up to the scheme to specify if it follows those
contracts or not.

-- 
Bruno Dumon                             http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
bruno@outerthought.org                          bruno@apache.org

Re: [RT] ComponentizedProcessor (was RE: Migrating TreeProcessor to Fortress)

[Berin Loritsch <bl...@apache.org>]

Bruno Dumon wrote:
> On Wed, 2003-11-12 at 12:02, Berin Loritsch wrote:
> 
>>Sylvain Wallez wrote:
>>
>>>Unico Hommes wrote:
>>>
>>>
>>>
>>>>Wild idea: context:/ identifies the current context, context:// 
>>>>identifies the root sitemap? Like in cocoon: protocol?
>>>> 
>>>>
>>>
>>>Great idea (again!). Currently, the "context:" protocol requires the 
>>>double-slash and links to the root sitemap, so we can implement this 
>>>additional behaviour with a single slash with no compatibility break. 
>>>And the similarity with "cocoon:" makes it easy to understand.
>>>
>>>This makes me think that "cocoon:" must also be be relative to the 
>>>"current" sitemap, and not that handling the request.
>>
>>BAD IDEA.
>>
>>Please, you are adding contracts to the URL spec that aren't there.
> 
> 
> Not really true. The basic structure of an URL is:
> 
> <scheme>:<scheme-specific-part>
> 
> and the interpretation of the scheme specific part depends on the
> scheme.
> 
> 
>>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.


And don't forget that URLs do have the concept of *resolving* relative
URLs.  THose are the contracts I am refering to.