[
Lists Home |
Date Index |
Thread Index
]
Hi Jonathan,
> As of the latest XQuery 1.0 WD, it *is* based on named typing, and
> supports derived types.
Good; that reassures me immensely.
> Here's the basic intuition: assert as wants to guarantee, at static
> analysis time, that an expression will always return an instance of
> the required type. Let's say we have the types Person, Surgeon, and
> BrainSurgeon. If the required type is Surgeon, but the computed type
> of an expression is Person, assert fails, because some people are
> not surgeons. At run time, if static analysis has been done, there
> is no need for assert as to do anything at all, so it is a no-op. Of
> course, if the implementation does not do static analysis, there is
> still work to be done. Assert is not willing to take any chances,
> and leaves nothing to be done at run time.
>
> Treat is similar, but treat is more open minded. If the required
> type is Surgeon, and the computed type of the expression is Person,
> treat says, "well, some people are surgeons, after all, let's wait
> and see." At run time, it looks at the instance, and returns the
> error value if the instance is not a surgeon.
>
> Does that help?
Sort of, though I still don't understand why it's necessary to make
the distinction. You're checking the same thing, but in one case the
error occurs at compile time and in the other then the error occurs at
run time. Even "treat as" gives you more information during static
analysis then casting does in Java, say. I'm sure the reasons would
become clear if I spent some time writing some queries. Or perhaps you
can explain when you'd use assert rather than treat?
>>Finally, "validate", which takes the result of an expression and
>>validates it, usually in some context. Again there's no use case in
>>the XQuery Use Cases document, so it's hard to tell how the WGs are
>>imagining this will be useful. The only thing that I can think of is
>>that this is a way of adding default values to elements and
>>attributes that you generate; but then, if you're generating those
>>nodes, surely you can indicate what type they are when you generate
>>them rather than taking an extra step to do so? So again, I don't
>>see any reason for validate to be present in XSLT, but there might
>>be one that I'm not aware of.
>
> I take your point on validate. Actually, several use cases have been
> used to develop this proposal, and it would be helpful to add them
> to our use cases document. I was a bottleneck on the latest release
> of the use cases document, and I just didn't have time for new
> material. We should consider this for the next cycle, I think.
Perhaps you could share one with us before the next cycle?
Cheers,
Jeni
---
Jeni Tennison
http://www.jenitennison.com/
|
