Return-Path: Delivered-To: apmail-xml-cocoon-dev-archive@xml.apache.org Received: (qmail 97454 invoked by uid 500); 10 Oct 2002 08:54:26 -0000 Mailing-List: contact cocoon-dev-help@xml.apache.org; run by ezmlm Precedence: bulk list-help: list-unsubscribe: list-post: Reply-To: cocoon-dev@xml.apache.org Delivered-To: mailing list cocoon-dev@xml.apache.org Received: (qmail 97420 invoked from network); 10 Oct 2002 08:54:25 -0000 Content-Type: text/plain; charset="iso-8859-1" From: Torsten Curdt Organization: dff internet & medien To: cocoon-dev@xml.apache.org Subject: Re: [Announcement] sitemap variables Date: Thu, 10 Oct 2002 10:56:46 +0200 User-Agent: KMail/1.4.1 References: <1034215741.811.45.camel@defiant> <3DA4E4E8.9050301@gmx.de> In-Reply-To: <3DA4E4E8.9050301@gmx.de> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Message-Id: <200210101056.46427.tcurdt@dff.st> X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N On Thursday 10 October 2002 04:24, Joerg Heinicke wrote: > >>We already have XPath. Why use it? Because its like all computer rela= ted > >> thing teached us for years. Everybody know that ".." means parent. > > > > but the question is - what means child? this still stands... > Sorry for my destructiveness, but I don't see any particular reason for > adding a new path description. simplification - hey, you don't have to use it... > > but I also not very clear myself it is really necessary or useful. an > > example would be: > > > > > > > > > > > > > > > > > > the absolute refering of the result of the first action would save yo= u > > from counting the levels for each position where you want to use the > > variable. > > Which means in XPath fromfirstaction in every level ;-) So it's only > confusing. why do you insist on xpath? only thing it has in common with xpath is "../"!? > > > > > > > > > > > > > > > > and as soon as you surround a subtree of the pipeline (insert another > > act e.g.) you currently have to add a "../" on each use of a variable > > from the parent tree. > > Where you must add a '/' on each use of a variable from the subtree. So > is there really a simplification? no - you don't have to (even must not) for the subtree. will still be no matter how deep you nest the subtree.. as long as the you don't refer = to=20 anything in the subtree you don't have to add anything. if you refer to=20 something inside the subtree you could use search and replace over the wh= ole=20 file to add a '/'. while this is not possible with '../' because you have= to=20 consider each individual position inside the tree. well, you didn't comment the first one... at least for us I can see a a major simplification. > The only way out of adding '/' or '../' to variable uses from outer or > inner tree is the direct accessing of variables via Ilya's proposal. So > in my opinion it's nice, independent of possibility of implementation. IMO the current proposal does not have an acceptable syntax yet. it could= be=20 an additional way with an acceptable syntax though. but there should also= be=20 a "counter part" for "../" anyway. -- Torsten --------------------------------------------------------------------- To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org For additional commands, email: cocoon-dev-help@xml.apache.org