RE: [xml-dev] Defining non-WXS datatypes

["Dare Obasanjo" <dareo@microsoft.com>]

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@jenitennison.com] 
Sent: Friday, July 18, 2003 1:55 AM
To: Dare Obasanjo
Cc: xml-dev@lists.xml.org
Subject: Re: [xml-dev] 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/