Return-Path: 
 <cocoon-dev-return-31921-apmail-xml-cocoon-dev-archive=xml.apache.org@xml.apache.org>
Delivered-To: apmail-xml-cocoon-dev-archive@xml.apache.org
Received: (qmail 60218 invoked by uid 500); 12 Oct 2002 18:57:20 -0000
Mailing-List: contact cocoon-dev-help@xml.apache.org; run by ezmlm
Precedence: bulk
list-help: <mailto:cocoon-dev-help@xml.apache.org>
list-unsubscribe: <mailto:cocoon-dev-unsubscribe@xml.apache.org>
list-post: <mailto:cocoon-dev@xml.apache.org>
Reply-To: cocoon-dev@xml.apache.org
Delivered-To: mailing list cocoon-dev@xml.apache.org
Received: (qmail 60206 invoked from network); 12 Oct 2002 18:57:20 -0000
Message-ID: <111b01c27220$f1b0a200$0100a8c0@MAUCHI>
From: "Ivelin Ivanov" <ivelin@apache.org>
To: <cocoon-dev@xml.apache.org>
References: <CC92E7C2663B1D498A745BD686C45E1F3F2D18@exch2000.cti2.com>
 <1034215741.811.45.camel@defiant> <3DA4E4E8.9050301@gmx.de>
 <200210101056.46427.tcurdt@dff.st> <3DA568F7.3090709@gmx.de>
 <1034263269.3da59ae52bf97@imp.dff.local> <3DA5B214.1020705@anyware-tech.com>
 <3DA5C6DF.1070400@kaon.com> <3DA5FEF9.8010205@apache.org>
 <3DA691DA.50702@anyware-tech.com> <3DA6DE91.2090906@apache.org>
 <3DA8485D.8040909@apache.org> <10eb01c2720c$9751f520$0100a8c0@MAUCHI>
 <3DA8552E.2040007@anyware-tech.com>
Subject: Re: [Announcement] sitemap variables
Date: Sat, 12 Oct 2002 13:55:33 -0500
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2600.0000
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N


I hear you.

Uniqueness on a path might lead to some confusion in everyone but the most
pipeline literate developers.
The reason is that all the possible paths constitute a pretty complex
directed graph.

A global uniqueness on the other hand might be more restricting than
necessary but is conceptually simple.

Additionally using global ids may in future allow things like extending
component configuration.

For example in a local sitemap, I may want to do something like

<transformers>
    <transformer extends="xslt">
        <use-request-parameters>true</use-request-parameters>
    </transformer>
</transformers>


This is a consise notation declaring that the "xslt" transformer will use
the request parameters in this sitemap and its sub-sitemaps (unless
overriden explcicitly in a sub-sitemap).

This of course makes a little unclear what is type vs id vs name.
I will let someone else comment on this.


Ivelin




----- Original Message -----
From: "Sylvain Wallez" <sylvain.wallez@anyware-tech.com>
To: <cocoon-dev@xml.apache.org>
Sent: Saturday, October 12, 2002 12:00 PM
Subject: Re: [Announcement] sitemap variables


> Ivelin Ivanov wrote:
>
> >----- Original Message -----
> >From: "Giacomo Pati" <giacomo@apache.org>
> >To: <cocoon-dev@xml.apache.org>
> >Sent: Saturday, October 12, 2002 11:05 AM
> >Subject: Re: [Announcement] sitemap variables
> >
> <snip/>
>
> >>>know what? I like it. It seems a pretty nice solution and the use of
> >>>anchor-like syntax is simple and understandable.
> >>>
> >>>So you get my +1 on this.
> >>>
> >>>
> >>I don't know if the attribute should be called "name"? Isn't "id" the
> >>right one for that? This would also ensure there are no duplicates in a
> >>sitemap.
> >>
> >>
> >
> >I had exactly the same thought, but didn't want to be the first to muddy
the
> >waters after such a heavy discussion.
> >id will align it with the concept usually used in other XML schemas.
> >For example in ANT, each element has an id and can be refered anywhere in
> >the script later by a refid attribute.
> >
> >
>
> I also thought of "id", but I'd like to avoid this no-duplicate
> constraint, hence "name" : a sitemap is often consituted of similar
> pipeline patterns, and the same name will IMO often be associated with
> statements having the same role in different branches of the sitemap.
>
> Example :
>
> <map:pipeline>
>   <map:match pattern="foo-*" name="topmatcher">
>     <deep-nesting...>
>       <map:generate src="foobase-{#topmatcher:1}"/>
>     </deep-nesting...>
>   </map:match>
>
>   <map:match pattern="bar-*" name="topmatcher">
>     <deep-nesting...>
>       <map:generate type="bar" src="{#topmatcher:1}"/>
>     </deep-nesting...>
>   </map:match>
> </map:pipeline>
>
> An important difference between a sitemap and an Ant file is that
> pipeline construction follows a path in the sitemap hierarchy, and thus
> a statement cannot use variables defined by a statement that isn't one
> of its ancestors. This isn't true in Ant files where targets can be
> referenced from anywhere in the file.
>
> I also discussed about name overloading on a single path at
> http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=103432718409833&w=2
>
> I guess you may not like this overloading. In that case, what about
> requiring uniqueness of names _on a path_, meaning the same name can be
> used in different branches of the sitemap tree ?
>
> Sylvain
>
> --
> Sylvain Wallez
>  Anyware Technologies                  Apache Cocoon
>  http://www.anyware-tech.com           mailto:sylvain@apache.org
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org
>


---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org