- From: David Carlisle <davidc@nag.co.uk>
- Date: Mon, 1 Dec 2003 11:19:40 GMT
- To: mrys@microsoft.com
- Cc: public-qt-comments@w3.org
> It may be better to either use exactly-one() or zero-or-one(), > use [1], use a for iterator, I am usually in favour of static typing, but in a language like Standard ML, the type system is closely matched to the values and operations in the language, and type errors almost always reflect real errors (ie run time errors or incorrect results would have occurred without the static check). However the existence of exactly-one() appears to be an admission that the type system (or at least the type inference) in use here is really a terrible match to the underlying data and operations and I fear that with the current definitions a system using the static typing as specified in the FS is basically unusable, the use of the static type system will generate far more errors than it ever detects. Requiring the user to have to code special functions to work round deficiencies in the static typing is a usability disaster. It is probably infeasible to reliably detect whether expressions match node() rather than node()* as a static check as the cardinality of the result sequence depends on too many run time factors (eg with the exampbe //book[isbn="1558604820"] here, unless isbn is of type ID you haven't really a hope of statically telling that this returns a single node) In Xquery an item is the same as a sequence of one item, and it would probably make sense to not try to distinguish these at the static typing level and not try to statically distinguish any sequence based on its cardinality (including cardinality of one). Obviously if node() and node()* were the same static type the type system is in some sense weaker, but I think in practice the result would be that the system was far more usable with far fewer spurious errors, and no requirment for fn:exactly-one() and friends. > or define is and <<,>> using existential quantification. That might work for "is" but in practice with the current type definitions, all user defined functions are going to have to do something similar. If you type your function as requiring node() it is virtually unusable as so few expressions can be statically typed as returning a node. David ________________________________________________________________________ This e-mail has been scanned for all viruses by Star Internet. The service is powered by MessageLabs. For more information on a proactive anti-virus service working around the clock, around the globe, visit: http://www.star.net.uk ________________________________________________________________________
Received on Monday, 1 December 2003 06:20:06 UTC