cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sylvain Wallez <sylvain.wal...@anyware-tech.com>
Subject Re: [Announcement] sitemap variables
Date Thu, 10 Oct 2002 17:00:04 GMT
tcurdt@dff.st 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:sylvain@apache.org



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


Mime
View raw message