All,
I took the liberty yesterday to ask feedback from Mike Kay about our
discussion on the choose() function, providing an explanation of the
issue, a link to Joyn's summary of the discussion, and to the meeting
notes. He was kind enough to respond with the attached email and allowed
me to forward it to public-forms for the group's consideration.
-Erik
--
Orbeon Forms - Web Forms for the Enterprise Done the Right Way
http://www.orbeon.com/
Forwarded message 1
Thanks.
I can't resist saying something about the general situation: the XForms WG
is coming dangerously close to forking the XPath spec; it's not acceptable
within W3C to do that and I'm sure representations will be made about it.
Schema WG are doing the same thing, so it's a wider issue and needs to be
managed with a broader perspective.
As for the detail, it seems to me to make sense both from an XPath 1.0 and a
2.0 perspective to do no type conversion.
1.0 is dynamically typed; there are other expressions whose type cannot be
predicted statically (notably a variable reference); the system already has
to deal with polymorphic operators such as [] where the semantics depend on
the run-time type. The note you cited gives an argument based on the ability
to do static typing, but the scope for that in 1.0 is already very limited.
General comparisons in 1.0 do a conversion of one value to the type of the
other, but it's not a huge success, and gives some very strange results.
It's necessary there, it's not needed here.
Consider [$nodes = choose(@x, @x, 0)]. This should mean [if (exists(@x) then
($nodes = @x) else ($nodes = 0)]. But doing conversion you would convert @x
to a number, which might well be NaN, causing the comparison to fail even if
$nodes contains @x! Doesn't make much sense to me.
The results are even more bizarre when the type isn't known statically:
[$nodes = choose(@x, @x, $p)].
(But perhaps XForms doesn't allow variable references, I don't know).
XPath 2.0 allows the branches of if-then-else to have different types.
Here's a use case:
sum($sequence, if ($param) then $xs:duration('PT0S') else 0)
where the second argument of sum() gives the value that should be returned
if the sequence is empty. Here's another, where we assume $node has a schema
definition which assigns a union type:
if (data($node) instance of xs:integer) then $node+1 else data($node)).
In short:
(a) I don't think the XForms WG should be unilaterally extending the XPath
language in this way. The more it departs from XPath 1.0 now, the harder it
will be to bring things back into line later. You're not doing users a
service if they have to remember 4 different dialects of the language.
(b) If it has to be extended then it should stay as close to the semantics
of XPath 2.0 as possible
(c) XPath 2.0 allows the two branches of if/then/else to have different
static types and different dynamic types, so long as (in both cases) they
conform to the required type. There's no good reason for doing anything
different from that.
Feel free to forward the response.
Michael Kay
http://www.saxonica.com/