[Bug 12951] Simple mapping operator

http://www.w3.org/Bugs/Public/show_bug.cgi?id=12951

--- Comment #3 from Evan Lenz <evan@evanlenz.net> 2011-06-15 20:02:23 UTC ---
Thanks, Michael, for the quick, detailed response.

I like the alternative function call syntax you gave, but I would hope it does
not substitute for the simple mapping operator (allowing arbitrary expressions
and not just function calls). In other words, it would be great to have both,
but if I had to choose one, I'd go with the more general mapping operator
(regardless of the chosen syntax). I would also hope and expect this operator
to be a part of XQuery, not just XSLT, whether or not the map data type gets
accepted into XQuery.

If syntax is the obstacle, you could remove the restrictions on "/" so that it
behaves as a general mapping operator (if less simple).

I think this can be worked out in a backward-compatible, unsurprising way so
that what currently (in XPath 2.0) returns an error (value sequences on LHS and
heterogeneous node/value sequences anywhere) will in XPath 3.0 validly return a
sequence.

I think this rule works: If the sequences returned by a RHS step contain no
atomic values, then they are "unioned" (sorted into document order and
duplicates are removed). Conversely, if any of the sequences returned by a RHS
step include an atomic value, then the sequences are "concatenated" (sequence
order is preserved and duplicates are not removed).

This actually simplifies the current rules listed here:
http://www.w3.org/TR/xpath20/#id-path-expressions  #1 remains unchanged, #3 is
deleted, and #2 is changed slightly to read something like this:

2. If any evaluation of E2 returns a sequence that includes an atomic value,
these sequences are concatenated, in order, and returned.

Then remove err:XPTY0018 and err:XPTY0019.

For example, these expressions would now be legal (and well-defined):

/items/item/substring-before(.,' item')/upper-case(.)
(1 to 3)/concat('#',.)

And in my original post's example, you'd just replace "!" with "/".

The gotchas would then be unique to where the gotchas already are. (No new
gotchas.)

E.g., the following expression would still return <foo> elements in
implementation-defined order (document order).

$sorted-document-nodes/foo

But that gotcha already exists in XQuery 1.0/XSLT 2.0.

If I could summarize my request, it would be "Please remove what feel like
arbitrary restrictions." (You could make an analogy with the abolishment of the
result tree fragment in XSLT 1.0.) Unless there is some reason why this doesn't
actually work, on balance I would prefer this to adding new syntax to the
language.

-- 
Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.

Received on Wednesday, 15 June 2011 20:02:25 UTC