Torsten Curdt wrote:
> On Thursday 10 October 2002 04:24, Joerg Heinicke wrote:
>
>>>>We already have XPath. Why use it? Because its like all computer related
>>>>thing teached us for years. Everybody know that ".." means parent.
>>>
>>>but the question is - what means child?
>>
>
> 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).
>>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:
>>>
>>> <map:match pattern="**.html">
>>> <map:act type="..">
>>> <map:act type="..">
>>> <map:generate src="{//fromfirstaction"/>
>>> </map:act>
>>> <map:generate src="{//fromfirstaction"/>
>>>
>>>the absolute refering of the result of the first action would save you
>>>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 "../"!?
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.
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.
>>> <map:match pattern="**.html">
>>> <map:act type="..">
>>> <map:act type="..">
>>> <map:generate src="{../fromfirstaction"/>
>>> </map:act>
>>> <map:generate src="{fromfirstaction"/>
>>>
>>>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.
>
> <map:match pattern="**.html">
> <map:act type="..">
> <map:act type="..">
> <map:generate src="{//fromfirstaction"/>
> </map:act>
> <map:generate src="{//fromfirstaction"/>
>
> will still be
>
> <map:match pattern="**.html">
> 1 <map:act type="..">
> 2 <map:act type="..">
> 3 <map:act type="..">
> 4 <map:generate src="{//fromfirstaction"/>
> 5 </map:act>
> 6 <map:generate src="{//fromfirstaction"/>
>
> no matter how deep you nest the subtree.. as long as the you don't refer to
> anything in the subtree you don't have to add anything. if you refer to
> something inside the subtree you could use search and replace over the whole
> file to add a '/'. while this is not possible with '../' because you have to
> consider each individual position inside the tree.
At least I can see now the little advantage while adding a new act: Either
all references to one special <map:act/> or none must be changed. So if you
added <map:act> in line 1, both //fromfirstaction must be changed to
///fromfirstaction. Otherwise if you added <map:act> in line 3 no reference
must be changed. Of course this is different to the bottom-up method using
"../".
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.
Regards,
Joerg
--
System Development
VIRBUS AG
Fon +49(0)341-979-7419
Fax +49(0)341-979-7409
[EMAIL PROTECTED]
www.virbus.de
VIRBUS hat jetzt als erster deutscher Softwarehersteller die Zertifizierung
für den 3D Secure-Authentifizierungsstandard "Verified by Visa" erhalten.
Details unter
http://www.virbus.de/de/press/pressemitteilung/20020828_verified_by_VISA.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
