This is the mail archive of the
xsl-list@mulberrytech.com
mailing list .
Re: Re: mapping (Was: Re: Re: . in for)
- From: Dimitre Novatchev <dnovatchev at yahoo dot com>
- To: xsl-list at lists dot mulberrytech dot com
- Date: Wed, 9 Jan 2002 01:55:27 -0800 (PST)
- Subject: [xsl] Re: Re: mapping (Was: Re: Re: . in for)
- Reply-to: xsl-list at lists dot mulberrytech dot com
Jeni Tennison <jeni at jenitennison dot com> wrote:
> True - with most operators, both operands are evaluated with the same
> focus and the result is combined in some way.
>
> But this isn't true for all "operators": the / "operator" for
> instance:
>
> table / row
>
> does not involve getting the child table elements of the context node
> and combining them in some way with the child row elements of the
> context node. Instead, the expression 'row' is performed with a
> focus derived from the expression 'table'.
>
> The "dereference operator" is similar:
>
> figref[1]/@refid => figure
>
> Perhaps it's therefore wrong to call these syntactic constructs
> 'operators' (is there a better name?). My intent was that 'map'
> behaved in a similar way to '/'.
I guess a similarity with '/' will lead to confusion only -- the ***difference*** is
bigger as '/' produces a node-set and not (any) sequence.
Perhaps one would want to write something like this:
$departments/(lower-case(.))
It doesn't seem good to me.
Cheers,
Diitre Novatchev.
__________________________________________________
Do You Yahoo!?
Send FREE video emails in Yahoo! Mail!
http://promo.yahoo.com/videomail/
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list