[EMAIL PROTECTED] wrote: ><snip/> > > > >>>this still stands... >>> >>> >>I left it out, because it's the most difficult thing ;-) Childs in pipelines >> >>are the nested components, aren't they? But what's the consequence for this >> >>syntax? The child tree you posted in a former mail uses components as >>directories and variables as files (or elements and attributes in XML). >> >> > >What you refer to was the tree of the sitemap variables which is actually >no "real" tree. it's more stack with maps in it... > ><snip/> > > > >>>>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 "../"!? >>> >>> >>Why? It's not only XPath, that was an example. Another example is directory >> >>navigation. You would not use ///build.xml to get >>/home/jheinicke/development/build.xml, because it's ambiguous. There could >>be a file /usr/local/development/build.xml, which would use the same >>abbreviated path. >> >> > >true for that case - but you ignore the facts. let's assume you can always only >have a single directory within a directory (that whould compare to the result >tree in fact) ...then it would not be ambiguous - wouldn't it? > > > >>With your syntax you say: go to root component and went down the tree, but >>only this path, where I am a child. So it's no more ambiguous, but >>confusing. AFAIK this behaviour is known nowhere, so you invent a new path >>language. And I don't know if this really must be or if it is useful. >> >> > >Well, there is none know syntax... does this mean we shouldn't invent one???? >We need to find a way to specify the absolute level which is a position >in a list (not a tree!). As I've already posted an alternative syntax using a >the direct number representation. But I doubt it's much nicer and the relation >to '../' is not obvious. > ><snip/> > > > >>At least I can see now the little advantage while adding a new act: >> >> > >finally ;) > > > >>In conclusion you have convinced me with the method in general, so only >>still the syntax is poor. But I can't provide a better proposal. It should >>not use known path expressions from XPath or directories, which do >>completely different things and are so confusing. >> >> > >Well, I hear you. but I don't wanna resign from this advantage because people >could take something for an xpath which actually is no xpath. You also >understand the axis notation "self::node" although it "clashes" with the well >known C++ syntax. It's the definition of context that differs... > >Of course I'd be happy if we could find a more obvious syntax for all of us :) > >
The sitemap variables are, as you say, a list and not a tree. Writing "../" makes sense because - a tree node having only one parent - it has the same meaning in a list an in a tree : "go to the previous element". To crawl the list from its start, using the "/" seems to me a bad choice (see all the confusion it produces) since our minds have been biased for years and see in this character the symbol of a *tree* navigation, which must be followed by something identifying a child in the tree. So we should invent another syntax, and a numbered one seems good to me as - let's remind it - we're navigating in a list. So what about a numbered syntax such as "[/pos/]/name/". Pos is a number which, if positive starts from the root, and if negative starts from the current element. So : - "[1]foo" is the root variable "foo" - "[2]1" is the variable "1" of the top-level matcher - "[-1]foo" is the "foo" variable of the immediate parent of the current statement - etc. Note that the index comes _before_ the variable name to avoid any confusion with XPath or Java arrays where "foo[2]" means "second element of foo". Of course, we keep the "../" syntax. My 0.02 euro... Sylvain -- Sylvain Wallez Anyware Technologies Apache Cocoon http://www.anyware-tech.com mailto:[EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
