[
Lists Home |
Date Index |
Thread Index
]
At 03:11 PM 5/7/2002 -0400, Elliotte Rusty Harold wrote:
>At 10:17 AM -0700 5/7/02, Jonathan Robie wrote:
>
>>What behavior would you like XQuery and XPath to adopt that is different
>>from what is in the current Working Drafts? Can you illustrate the
>>advantages of this behavior with an example?
>
>Here's just one:
>
> avg( input()//person/name )
>
>You say you want this to fail. I say I want it to return NaN if any of the
>identified name elements contains a non-number and the actual average if
>they all do contain strings that can be parsed as numbers. Neither of us
>is right. Neither is wrong. We simply have different needs in our local
>environments. Tomorrow I may move to a different local environment with
>different needs.
If error handling is different in each environment, then real
interoperability is very hard to achieve.
>I also have a use-case of teaching this stuff that requires it be simple
>and intelligible. Based on that, I strongly oppose systems that have 20
>different ways to do the same thing, and systems that mangle multiple
>layers together instead of allowing them to be separated out and used
>independently. It makes my job more complicated.
I teach XQuery too, so I agree with this need.
As for layering, I think that many layers, each with a different type
system, tends to lead to more complex systems, not less complex systems. To
repeat a limerick from an earlier discussion:
I've completely rejected the load
Of specs that would seek to erode
My 12 software layers
And typeless compares
-- The complexity's now in my code!
If what you are doing is querying persistent XML data or a persistent view
of XML data, and the data is typed data, I think that the integrated type
system really simplifies things a lot.
> From my perspective, those who want typing need to demonstrate the
> use-cases. Looking at the XQuery use-cases document I don't see many
> there. Furthermore, I specifically reject the following use-case:
>
> 1.7.4.3 Q3 "Select all elements using datatypes from "XML Schema: Part
> 2" datatypes"
>
>That's wildly artificial. Are there any others?
This is a valid point. The use cases we have for strong typing are not
really in our documents, they have been presented privately, and I think we
need to work on this.
One use case is the Use Case R, which is currently too complex precisely
because it lacks a schema, which forces us to use casts to get some things
to come out right. Here are some examples:
1.4.4.2 Q2 - as is:
<result>
{
for $i in document("items.xml")//item_tuple
let $b := document("bids.xml")//bid_tuple[itemno = $i/itemno]
where contains($i/description, "Bicycle")
return
<item_tuple>
{ $i/itemno }
{ $i/description }
<high_bid>{ max(for $z in $b/bid return decimal($z)) }</high_bid>
</item_tuple>
sortby(itemno)
}
</result>
Without the cast, max() would sort according to the string value, not the
decimal value.
If we had a schema for this, and the schema said a bid is a decimal, we
could write this without the cast. Since we can currently only cast one
item at a time, we can also get rid of a FLWR:
<result>
{
for $i in document("items.xml")//item_tuple
let $b := document("bids.xml")//bid_tuple[itemno = $i/itemno]
where contains($i/description, "Bicycle")
return
<item_tuple>
{ $i/itemno }
{ $i/description }
<high_bid>{ max($z) }</high_bid>
</item_tuple>
sortby(itemno)
}
</result>
You can pick through the whole Use Case R and see many examples like this.
Every single cast is superfluous in these use cases, present only because
there is no schema.
There are two reasons I don't like these casts. One is that it is tedious.
The other is that when I cast, I tell the static type system that I think
I'm smarter than it is, and it will simply believe me that $z is a decimal.
If I'm wrong, this may result in an error which I will not encounter until
run time.
Jonathan
|
