Re: Extension candidates

Florent,

I think we have basically the same understanding, with only one exception.

>  Ok.  So I don't see what's the purpose of xx:nested-sequence() then.
> Maybe that's because I have my own vision of how to deal with nested
> sequences?  What I have in mind is a function that returns some kind
> of reference to a sequence.  This reference is an item().  It can then
> be added to any sequence in regular XPath expression.  A second
> function takes such a reference and return the original sequence back:
>
>    <xsl:variable name="ref" select="ex:sequence-ref((1, 2))"/>
>    <xsl:variable name="seq" select="$ref, 3"/>
>    ...
>    <xsl:sequence select="
>        sum((ex:sequence-from-ref($seq[1]), $seq[2]))"/>
>
>  That would return the integer 6, as sum would be called with the
> following sequence: (1, 2, 3).

I would rewrite the above example in an almost identical way:

    <xsl:variable name="ref" select="ex:sequence((1, 2))"/>
    <xsl:variable name="seq" select="$ref, 3"/>

The above is OK.
The same could be done like this:

    <xsl:variable name="seq2" select="ex:sequence($ref, 3)"/>

or

    <xsl:variable name="seq3" select="ex:sequence((1,2), 3)"/>

The last definition shows that in some cases we could omit (at least
at the surface) the need for ex:ref(). ex:sequence() makes a sequence
of all its arguments. Any argument is just one component of the
resulting sequence.
   ...
>    <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]))"/>

Certainly, there is no way XPath knows about our nested sequence, or
more exactly that the reference, which is the first component above,
represents another (nested) sequence.

Therefore, to cause the above to be evaluated correctly, I thought
initially to write it like:

    <xsl:sequence select="
        xx:evaluate(sum($seq[1], $seq[2])))"/>


This is to say: we do not sacrifice the good-looking XPath 2.0
expression style by interspering deRef-s into an expression.

Instead, we do all evaluations of refs in "another, 'ext' mode", and
the above shows this 'ext' mode implemented within xx:evaluate().

We can go even further if we introduce a special extension attribute:

   xx:extended-xpath-processing = "true"

for an <xslt:stylesheet/>.

This would instruct the XSLT processor to evaluate all XPath
expressions in "ext" mode.

For now, "ext" mode just means: in a context where a particular
item-type is expected and the item that is accessed is a ref(),
deref() it and continue the evaluation of the expression.

I hope this is clear, as it is very simple.

>
>    (1, [2.25, [2.4, 2.5, 2.6], 2.75], 3)
>
> what would you expect ex:sequence-from-ref($seq[2]) to return?  I
> suspect this is (2.25, 2.4, 2.5, 2.6, 2.75),

no,

just:

( 2.25, [2.4, 2.5, 2.6], 2.75)


> while I would say instead
> (2.25, [2.4, 2.5, 2.6], 2.75), that is, the inner sequence ref is not
> "resolved."
>

Yes, we agree about that. What is important is not to make the
ref/deref process visible at the surface. If we can achieve this, the
resulting expression language will be much more elegant.

>> >    ex:sequence-ref(seq as item()*) -> item()
>> >    ex:sequence-from-ref(ref as item()) -> item()*

Again, we do not differ on this. I would prefer to name the first
function just as xx:sequence(), and the second function just deref().
We could have a general xx:ref() function, that makes a ref for
anything, not just sequences.

However, what we should try to achieve is to eliminate (or bring to a
minimum) the need (for the user) to use these two functions on the
surface.

I already provided example how we can make a nested sequence without
explicitly making a ref().

Dereferencing behind the scenes will achieve the same in the other direction.



-- 
Cheers,
Dimitre