Re: Extension candidates

> > Extension types in Saxon (like the type of the result of 
> > saxon:function()), are in fact subtypes of xs:anyAtomic 
> rather than being a third kind of item.
> > That's largely a matter of implementation convenience, but it 
> > simplifies a lot of the rules.
> 
> I'm interested in why this make things simpler. I would have 
> thought it would bring up hard problems of how and whether to 
> allow casting, serialization etc.

In my implementation, I have zillions of places where I assume that an item
must be either an atomic value or a node. That's my problem, of course. But
I think that in the specs there are also zillions of places where the same
assumption is made, and trawling through to find them all would be quite
hard work. Adding a 20th primitive atomic type, with a few simple rules like
saying that the only casting allowed is to string, is less disruptive. That
doesn't mean it's necessarily the right thing to do - it's just an
observation.

Michael Kay
http://www.saxonica.com/