Re: Extension candidates

.>> I think we have basically the same understanding, with only one
>> exception.
>
>  Yes, I think so.  But I think this exception is an important point.
>
>>     <xsl:variable name="seq3" select="ex:sequence((1,2), 3)"/>
>
>  That could be a convenience function that would create a ref for any
> param that is not a singleton, but I don't think it could entirely
> replace a function that create a reference.

Nobody said it should .replace xx:ref(). It is just a more specialised
and readable function -- an xx:sequence constructor.

> Besides it requires
> variable parameter lists (could be a portability problem I guess.)
>

Not at all. Function overloads having up to 10 arguments would do the job.

>> >    <xsl:sequence select="
>> >        sum((ex:sequence-from-ref($seq[1]), $seq[2]))"/>
>
>> The main difference is here. I would prefer to write this as:
>
>>     <xsl:sequence select="
>>         sum($seq[1], $seq[2]))"/>
>
>  But that would then be impossible to manipulate references without
> dereferencing them.  For example, the snippet you wrote above:
>
>>     <xsl:variable name="ref" select="ex:sequence((1, 2))"/>
>>     <xsl:variable name="seq" select="$ref, 3"/>
>
>  If dereferencing was automatic, $seq would hold the plain sequence
> (1, 2, 3).

I didn't use the word "automatic". To make it clear, dereferencing
should take place whenever an item of a particula type is expected
(such as xs:double), but the argument is a ref. In your example above,
the "," operator accepts an item of any type as either its first or
second operand, so there is no type conflict and no need for deref().

However. if we had:

    sum($ref)

$ref is expected to be of type xx:numeric*. It isn't, so a deref()
takes place and thransforms the expression to:

  sum(1,2)

and then this is evaluated to the correct result: 3

I think this principle is quite clear:

"dereferencing should take place whenever an item of a particula type
is expected (such as xs:double), but the argument is a ref. "

> I think (de)referencing should be explicit.  The point is
> to be able to manipulate complex structures, so I think exposing
> explicitly the structure is a feature, not a bug.

It could be explixit and nobody could stop a programmer from doing so.
However it can also be performed behind the scenes as per the above
simple rule. In this way, XPath expressions are more readable and easy
to write, and considerably less error-prone.

-- 
Cheers,
Dimitre .