Re: mapping (Was: Re: [xsl] Re: . in for)

[Joerg Pietschmann <joerg.pietschmann@xxxxxx>]

Jeni Tennison <jeni@xxxxxxxxxxxxxxxx> wrote
> Mike wrote:
> > (But there are people in the XQuery WG who like keyword-based syntax
> > and mock this kind of thing as "line noise"....)

> Can we mock keyword-based syntax back?

Maybe, are there enough non-westerners in the WG?
The discussion in favor of keyword-based syntax is usually based
on them being "more intuitive". Now, the "intuitiveness" of
  for $e in $stuff return some-expr($e)
originates mostly in the resemblance of the standard western grammar
pattern Subject-Verb-Object (apart from the keywords itself). A
japanese might have a different opinion. (Well, for this special
example, having the variable definition $e near the values the
variable is bound to is also important)
If anecdotes count, all my chinese friends like C/C++ more than
Pascal, despite some of them took classes held by Prof. Wirth
himself. This may have something to do with the fact that they
regularly read and write what westerners deem to be cryptic signs,
and they may mock "while i<N do begin writeln(i);inc(i);end;"
as "line noise".

> > You get a spin-off of being able declare range variables in a predicate:
> Hubba hubba. Or that one David thought he'd solved:
>   $x//*[$e; not(following::*[name()=name($e)])]

I have an even better use case:
Suppose you have a set of a sort entity definitions, an entity being
identified by a package name and a normal name (unique within the package)
  <!ELEMENT entity (name,package,other-stuff+)>
Suppose you have two lists $a and $b of entity element nodes coming
from potential different documents and possibly containing duplicates
(in the sense that there is more than one definition with the same
name+package).
Suppose furthermore you want to process entity definitions from a which
are not in $b. The simple approach
  select="$a[not($b/name=name and $b/package=package)]" --- wrong!
does not work. If the nodes in $b came from the same document, a
compound key could help
  <xsl:key name="ent" match="entity" use="concat(name,'@',package)"/>
however, there is no way to make it work if $b is assembled from
multiple documents. With an explicit variable,
  select="$a[$e;not($b[name=$e/name and package=$e/package])]"
should work. I'll ignore the possibility to solve it with the XPath
2.0 "for" operator here.

Just for fun: Would
  $a[$&#255;;not($b[name=$&#255;/name and package=$&#255;/package])]"
work the same way?

Furthermore, from M.Kay:
> Now you're confusing me. How can "expression" be supplied as an argument to
> a function if expressions are not a data type?
The same way the "for" operator takes an expression as operand: Declare
those functions to be something special and avoid talking about details
which others might not want to hear. This strategy seemed to have worked
when LISP acquired setq and progn the first time.

> The one we are currently inventing is "distinct" (select the items in $x
> that have distinct values for f(x)).

I used the concat-for/mapconcat because i could plausibly have it take
the delimiter as a further argument (or operand) in order to ram home the
point that adding operators is more hassle than adding functions.
Mr.Kay, what's your point of view as an implementor?

Regards
J.Pietschmann

 XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list