Re: Extension candidates

Michael Kay wrote:
>>> 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.

Fair enough. I've actually done the "trawl" through both my 
implementation and the XQuery spec at least, and it wasn't as bad as I 
thought it was going to be :-).

John

-- 
John Snelson, Oracle Corporation            http://snelson.org.uk/john
Berkeley DB XML:            http://oracle.com/database/berkeley-db/xml
XQilla:                                  http://xqilla.sourceforge.net