[
Lists Home |
Date Index |
Thread Index
]
Hi Bob,
[snip discussion on multiple inheritance for types]
> Are you aware of any work underway on a query/transform model with a
> more inclusive type system?
Well, we were talking a bit about it for XPath NG
(xpath-ng@lists.fourthought.com), but discussion on that has dwindled
recently. I was thinking along the lines of each item conceptually
having a sequence of types, with any type-related rules being based on
whether that sequence contained a particular type or not. But I'm not
sure anyone else was convinced.
Alternatively, it might be possible to take a very liberal
interpretation of the XPath 2.0 typing semantics, especially if you
ignore the Formal Semantics (which only applies when doing static type
checking).
In XPath 2.0, every element/attribute/atomic value has a single type;
checking whether an item is of a particular type is done by referring
to the in-scope type definitions. Types can be anonymous (given an
implementation-dependent name), which, as I suggested, means that you
can create a novel type for a particular element/attribute based on
the combination of types that it matches.
The actual content of the in-scope type definitions is deliberately
very hazy. There's an unwritten assumption that these type definitions
will be from an XML Schema schema, but because it's unwritten there's
no reason not to use type definitions from some other location, or
defined in some other way, especially because typing is all based on
named typing (rather than looking at the actual structure the type
specifies).
So it would be perfectly possible to base the in-scope type
definitions on "types" defined in a RELAX NG schema or a datatype
library or whatever. (In fact it's likely that individual
implementations will supply their own built-in types, for example
based on database schemas or to support the extension functions that
they provide.)
The types for atomic values do have to be derived "by restriction"
from the built-in XML Schema types (otherwise the casting wouldn't
work), but that's not a big deal; it's easy enough to say that other
types are derived by restriction from xs:string or xs:double. And it's
perfectly true to say that a value that is, for example, both a
xs:boolean and a xs:integer is derived by restriction from both
xs:boolean and xs:integer, since the value must, by definition, be a
legal xs:boolean and a legal xs:integer.
As I mentioned, the difficulties come when you start looking at the
polymorphic operators and functions, because the definitions here
assume that a value is only of a single type. I guess an
implementation supporting multiple inheritance would pick the first
type from the list and then apply the XPath 2.0 semantics based on
that. Of course this prevents you from doing anything funky like
saying "base a comparison on the first *shared* type of the two values
to be compared", so that, for example, you could compare the xs:boolean
| xs:integer "1" with the xs:token | xs:boolean "true".
Cheers,
Jeni
---
Jeni Tennison
http://www.jenitennison.com/
|
