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...
> 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 "../"!?
> > <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">
<map:act type="..">
<map:act type="..">
<map:act type="..">
<map:generate src="{//fromfirstaction"/>
</map:act>
<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.
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
an additional way with an acceptable syntax though. but there should also be
a "counter part" for "../" anyway.
--
Torsten
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
