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.


+1



> 
> (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.

It seems logical to have an operation *confirming the use of a ref".

  useRef(ref)

that will increment a reference counter.

The rule will be that the user should first use useRef() on a ref before copying this to another location -- for every single copying of a ref. 

The result of dereferencing a copy of a ref that was not preceded by useRef() are unpredictable.

Or it will be even better to combine claiming use and copying in one operation:

   string copyRef(ref)

which returns a string that can be safely dereferenced. The use of "string" here is not important. Anything that can be stored/passed-around is OK.

 
Cheers,
Dimitre