Subject: Re: mapping (Was: Re: [xsl] Re: . in for) From: Joerg Pietschmann <joerg.pietschmann@xxxxxx> Date: Mon, 14 Jan 2002 10:16:39 +0100 |
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[$ÿ;not($b[name=$ÿ/name and package=$ÿ/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
Current Thread |
---|
|
<- Previous | Index | Next -> |
---|---|---|
Re: mapping (Was: Re: [xsl] Re: . i, naha | Thread | Re: mapping (Was: Re: [xsl] Re: . i, Joerg Pietschmann |
Re: [xsl] what type of encoding?, Oscar Rueda | Date | Re: [xsl] what type of encoding?, rafael vazquez |
Month |