Cart
|
[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] RE: Defining non-WXS datatypes
 You are right that the biggest problems with xs:QName is that there is no canonical form [that is context independent]. However I still think having a datatype whose value is dependent on context is a bad thing because it limits how the data can be reused (e.g. I can't just move instances of an xs:QName or a relative URI from one part of the document to another or from one document to another without risking data corruption). I'll think more about the data type issue since the current status quo is a pet peeve of mine. -----Original Message----- From: Jeni Tennison [mailto:jeni@j...] Sent: Friday, July 18, 2003 1:55 AM To: Dare Obasanjo Cc: xml-dev@l... Subject: Re: Defining non-WXS datatypes 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
|
|||||||||
