<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 :) cheers -- Torsten --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
