Cart
|
[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: Non-deterministic content models
 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@l...), 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/ 
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! 
Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|
|||||||||
