[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: Defining non-WXS datatypes
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/
|
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
|