[
Lists Home |
Date Index |
Thread Index
]
Hi Dare,
>> I'm interested in which of the features you think are bad ideas?
>
> Datatypes that require context to be correctly interpreted are a bad
> idea. I can't see much benefit but lots of harm form actually
> formalizing how to create more messes like QNames-in-content.
I have a lot of sympathy with that standpoint, but the pragmatist in
me says that if markup languages use values like QNames, XPaths, and
relative URIs, which require context information to be interpreted,
then a datatype library needs to be able to represent that context.
Also, the RELAX NG datatype library interface has mechanisms for
passing in context information when validating, so it seems reasonable
to take advantage of that.
To my mind, the biggest problem with QNames, as defined in XML Schema,
is that there's no way to construct a normalized representation that
can be interpreted standalone, without context information. Whereas
you can resolve relative URIs into an absolute URI, there's no way
that you can normalize a QName in a way that doesn't completely depend
on the context in which it's going to be used. Perhaps a new datatype
library can define QNames in a different way, one that includes a
normalized version that's a legal representation (e.g. {uri}name).
As I mention, I haven't actually incorporated anything about accessing
context information as yet. Perhaps providing a mechanism for using
context information when *parsing*, but not having access to any
context information when *normalizing* (and hence serializing) will
help prevent people from replicating the QName-in-content mess by
forcing them to allow normalized versions of the datatypes that
*don't* rely on context information.
Or perhaps such datatypes should just be ruled out of scope, in the
same way that context-free languages such as XPath and XQuery can't be
supported. After all, there are always going to be some datatypes that
can't be represented...
>> What is it about type hierarchies that you're wary of?
>
> They are unnecessary and can lead to difficulty in mapping them back
> to existing domain models. On the other hand, what most folks really
> want is just a way to specify type promotion or type equivalence
> rules. Most programming and query languages don't need an integer to
> be the derived type of a decimal number for one to perform
> operations involving both types or to use them interchangeably.
I had two motivations for including type hierarchies. The first was to
provide a type hierarchy that XPath 2.0 and XQuery could use (since
they generally *do* rely on knowing that one type is derived from
another to perform operations involving both types and use them
interchangeably). The second was to make it easier for users to define
the datatypes by referring to similar datatypes rather than repeating
everything.
I'm very open to changes in this area. It would be really cool if we
could come up with a general mechanism that allowed what I've called
"datatype sharing" to be merged with datatype hierarchies and to
support something like multiple inheritance. I'll apply some more
thought to it, but I'd love to hear your suggestions.
Cheers,
Jeni
---
Jeni Tennison
http://www.jenitennison.com/
|
