You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Berin Loritsch <bl...@apache.org> on 2003/11/13 10:27:48 UTC

Re: Bastardized URL protocol

Vadim Gritsenko wrote:
> Stefano Mazzocchi wrote:
> 
> 
> <snip/>
> 
>> The only potential solution I see is something like
>>
>>  <generate src="cocoon:/path" xml:base="/">
>>  <generate src="cocoon:/path" xml:base=".">
> 
> 
> 
> I think that would not be correct usage of the xml:base... Correct usage 
> would be something like:
>  <generate src="path" xml:base="cocoon:/">
>  <generate src="path" xml:base="cocoon:">  <!-- or xml:base="cocoon:." -->
> 
> <snip/>

Wouldn't it be much more common to do something like this:

<pipelines xml:base="cocoon:">
     <pipeline>
         <match uri="**/foo">
            <generate src="path"/>
            <transform src="path"/>
            <serialize/>
         </match>
         <match uri="**/bar" xml:base="context:/foo/bar">
            <generate src="path"/>
            <transform src="path"/>
            <serialize/>
         </match>
     </pipeline>
</pipelines>

In other words, the xml:base attribute (according to spec) applies the the
URLs contained in the element it is declared in, as well as to all child
elements--unless a child element overrides it.


> 
>> but I'm not sure this makes things any easier or bugs any more 
>> evident. For sure, it's more verbose and for back compatibility, we 
>> still need to support cocoon://
>>
>> Thoughts?
> 
> Any of the above does not look neither elegant nor easier. I'd keep the 
> approach we have right now.
> 

Just because we have one protocol that is messed up and we can't change it
doesn't mean we should make the same mistakes.

For the Context protocol, I highly recommend doing something other than
the one slash vs. two approach used for the "cocoon" protocol.

*Something* doesn't have to mean using the xml:base approach outlined above.
But it does mean that we shouldn't repeat the same mistake.


Re: Bastardized URL protocol

Posted by Stefano Mazzocchi <st...@apache.org>.
On 13 Nov 2003, at 14:49, Berin Loritsch wrote:

> Stefano Mazzocchi wrote:
>
>>> Sigh.  I'm not going to force you guys not to make the same mistake 
>>> again.
>>> It seems I am the only one who doesn't like it, even though I 
>>> strongly
>>> encourage at least stripping out *one* of the forward slashes so 
>>> that a
>>> relative URI has no forward slashes at the beginning at all.
>> and break all sitemaps out there?
>
> As far as I know this was all about adding new semantics to the
> "context:" protocol--so I wanted to encourage everyone not to
> do it in the same way as the "cocoon:" protocol.  So no, not break
> all sitemaps out there.

Ah, ok. Lost the context, sorry.

But wouldn't it be even *more* confusing to have two different ways to 
handle with protocols?

--
Stefano.

Re: Bastardized URL protocol

Posted by Berin Loritsch <bl...@apache.org>.
Stefano Mazzocchi wrote:
> 

>> Sigh.  I'm not going to force you guys not to make the same mistake 
>> again.
>> It seems I am the only one who doesn't like it, even though I strongly
>> encourage at least stripping out *one* of the forward slashes so that a
>> relative URI has no forward slashes at the beginning at all.
> 
> 
> and break all sitemaps out there?
> 

As far as I know this was all about adding new semantics to the
"context:" protocol--so I wanted to encourage everyone not to
do it in the same way as the "cocoon:" protocol.  So no, not break
all sitemaps out there.


Re: Bastardized URL protocol

Posted by Stefano Mazzocchi <st...@apache.org>.
On 13 Nov 2003, at 11:35, Berin Loritsch wrote:

> Sylvain Wallez wrote:
>> Carsten Ziegeler wrote:
>>> Berin Loritsch wrote:
>>>
>>>> Just because we have one protocol that is messed up and we can't 
>>>> change it
>>>> doesn't mean we should make the same mistakes.
>>>>
>>>
>>> True.
>>>
>>>
>>>> For the Context protocol, I highly recommend doing something other 
>>>> than the one slash vs. two approach used for the "cocoon" protocol.
>>>>
>>>> *Something* doesn't have to mean using the xml:base approach 
>>>> outlined above.
>>>> But it does mean that we shouldn't repeat the same mistake.
>>>>
>>>
>>> Sorry, I haven't followed the whole discussion, so this might have 
>>> been already discussed: why can't we use a new protocol, e.g. 
>>> "sitemap:", so context:// is the context :), and sitemap:// resolves 
>>> relative to the current sitemap?
>>>
>>> Even using context:// and context:/ is fine for me. Users are used 
>>> to it anyway, even if it might not be the most perfect syntax.
>>>
>> +1. And since it perfectly matches the "cocoon://" vs "cocoon:/" 
>> difference, I think this will be the most easy to understand rather 
>> than "context://" vs "sitemap://".
>
> Sigh.  I'm not going to force you guys not to make the same mistake 
> again.
> It seems I am the only one who doesn't like it, even though I strongly
> encourage at least stripping out *one* of the forward slashes so that a
> relative URI has no forward slashes at the beginning at all.

and break all sitemaps out there?

--
Stefano.

Re: Bastardized URL protocol

Posted by Berin Loritsch <bl...@apache.org>.
Sylvain Wallez wrote:
> Carsten Ziegeler wrote:
> 
>> Berin Loritsch wrote:
>>  
>>
>>> Just because we have one protocol that is messed up and we can't 
>>> change it
>>> doesn't mean we should make the same mistakes.
>>>   
>>
>> True.
>>
>>  
>>
>>> For the Context protocol, I highly recommend doing something other 
>>> than the one slash vs. two approach used for the "cocoon" protocol.
>>>
>>> *Something* doesn't have to mean using the xml:base approach outlined 
>>> above.
>>> But it does mean that we shouldn't repeat the same mistake.
>>>   
>>
>> Sorry, I haven't followed the whole discussion, so this might have 
>> been already discussed: why can't we use a new protocol, e.g. 
>> "sitemap:", so context:// is the context :), and sitemap:// resolves 
>> relative to the current sitemap?
>>
>> Even using context:// and context:/ is fine for me. Users are used to 
>> it anyway, even if it might not be the most perfect syntax.
>>  
>>
> 
> +1. And since it perfectly matches the "cocoon://" vs "cocoon:/" 
> difference, I think this will be the most easy to understand rather than 
> "context://" vs "sitemap://".

Sigh.  I'm not going to force you guys not to make the same mistake again.
It seems I am the only one who doesn't like it, even though I strongly
encourage at least stripping out *one* of the forward slashes so that a
relative URI has no forward slashes at the beginning at all.

Do what you will.


Re: Bastardized URL protocol

Posted by Sylvain Wallez <sy...@apache.org>.
Carsten Ziegeler wrote:

>Berin Loritsch wrote:
>  
>
>>Just because we have one protocol that is messed up and we can't change it
>>doesn't mean we should make the same mistakes.
>>    
>>
>True.
>
>  
>
>>For the Context protocol, I highly recommend doing something other than the one slash vs. two approach used for the "cocoon" protocol.
>>
>>*Something* doesn't have to mean using the xml:base approach outlined above.
>>But it does mean that we shouldn't repeat the same mistake.
>>    
>>
>Sorry, I haven't followed the whole discussion, so this might have been already discussed: why can't we use a new protocol, e.g. "sitemap:", so context:// is the context :), and sitemap:// resolves relative to the current sitemap?
>
>Even using context:// and context:/ is fine for me. Users are used to it anyway, even if it might not be the most perfect syntax.
>  
>

+1. And since it perfectly matches the "cocoon://" vs "cocoon:/" 
difference, I think this will be the most easy to understand rather than 
"context://" vs "sitemap://".

Sylvain

-- 
Sylvain Wallez                                  Anyware Technologies
http://www.apache.org/~sylvain           http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Orixo, the opensource XML business alliance  -  http://www.orixo.com



Re: Bastardized URL protocol

Posted by Berin Loritsch <bl...@apache.org>.
Carsten Ziegeler wrote:
> Berin Loritsch wrote:
> 
>>Just because we have one protocol that is messed up and we can't change it
>>doesn't mean we should make the same mistakes.
>>
> 
> True.
> 
> 
>>For the Context protocol, I highly recommend doing something other than
>>the one slash vs. two approach used for the "cocoon" protocol.
>>
>>*Something* doesn't have to mean using the xml:base approach
>>outlined above.
>>But it does mean that we shouldn't repeat the same mistake.
>>
> 
> Sorry, I haven't followed the whole discussion, so this might have been
> already discussed: why can't we use a new protocol, e.g. "sitemap:",
> so context:// is the context :), and sitemap:// resolves relative
> to the current sitemap?
> 
> Even using context:// and context:/ is fine for me. Users are used
> to it anyway, even if it might not be the most perfect syntax.
> 
> But I'm against a more complicated way of doing this.

IMNSHO, context: and context:/ are much clearer than context:/ and context://.
IOW a relative URI should never have a beginning slash.  It is easier to spot
a mistake when it is between a character that is not there at all vs. not enough
characters.


RE: Bastardized URL protocol

Posted by Carsten Ziegeler <cz...@s-und-n.de>.
Berin Loritsch wrote:
> Just because we have one protocol that is messed up and we can't change it
> doesn't mean we should make the same mistakes.
>
True.

> For the Context protocol, I highly recommend doing something other than
> the one slash vs. two approach used for the "cocoon" protocol.
>
> *Something* doesn't have to mean using the xml:base approach
> outlined above.
> But it does mean that we shouldn't repeat the same mistake.
>
Sorry, I haven't followed the whole discussion, so this might have been
already discussed: why can't we use a new protocol, e.g. "sitemap:",
so context:// is the context :), and sitemap:// resolves relative
to the current sitemap?

Even using context:// and context:/ is fine for me. Users are used
to it anyway, even if it might not be the most perfect syntax.

But I'm against a more complicated way of doing this.

Carsten