Re: Extension candidates

> Dr. Kay, Colin,  and Altova developers, will it be too 
> difficult to implement the following principle:
> 
>   "The processor will try to recover of a typing error by using
>    dereferencing when one of the ill  arguments is a reference".
> 

Several points:

(a) that's not how I would express the rule. The natural way to write it
would be as an extension to the (poorly-named) function conversion rules in
XPath section 3.1.5. Something like:

* if the expected item type is an atomic type or node type, then the
supplied sequence is _dereferenced_

where dereferencing, like atomization, is defined as an operation that takes
any sequence and replaces any references in the sequence by the sequences
that they reference, recursively.

This rule should apply before the atomization rule.

(b) I would think very carefully before implementing such an extension to
the function calling semantics. Although the specs say very little about
what is allowed and what isn't when it comes to extension types. I think I'd
be happier, while we're still in the business of defining extensions, of
making the dereference operation something that the user has to invoke
explicitly; one can always add the implicit behaviour later when integrating
the extensions into the language.

This does seem to raise another point, however, which is that if the
dereference operation is recursive then there is no guarantee that it will
terminate.

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