Re: Extension candidates

Dimitre Novatchev wrote:

> On Thu, Dec 11, 2008 at 10:39 AM, Florent Georges wrote:

> >> * xx:nested-sequence() - produce a nested sequence object from
> >>   one or more components (usually at least one of them a
> >>   sequence)

> >  What do you mean by "a nested sequence object"?  I mean, I
> > understand "nestable sequence," but how can a sequence be nested
> > by itself?  I guess that's just a vocabulary point, but I'd prefer
> > to be sure.

> The sequence reference in fact identifies an extension object (in
> some programming language).

> A "nested sequence" means a non-flat sequence. Any member that is an
> xx:sequence itself, contributes to the nesting/shape of the sequence
> that contains it.

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

  Could you please provide a sample with ex:nested-sequence()?

> >> * operator [] for a nested sequence object - evaluate an XPath
> >>   2.0 predicate on the components of a nested sequence and select
> >>   the sub-sequence of components for which the predicate is
> >>   true()

> >  Interesting.  But I think defining an operator is looking for
> > trouble when defining extensions, a function providing the same
> > feature would be better IMHO.

> We should keep as close to standard XPath -like, as possible.

> Doing XPath operation with an xx:sequence will present the bulk of
> specification/design work.

  What's wrong with the following:

    ex:sequence-from-ref($ref)[the predicate]

> >  And maybe this is over specialized yet?  Why not just defining a
> > function to give the original sequence back from the nested
> > sequence object?

> Because the "original-sequence" may itself be an xx:sequence (nested
> sequence).

  I am not sure to understand.  Let me introduce square braquets to
represent sequence reference in XPath.  Given the following sequence
(containing three items, the second being a sequence ref):

    (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), while I would say instead
(2.25, [2.4, 2.5, 2.6], 2.75), that is, the inner sequence ref is not
"resolved."

  That's how I emplemented my sequence refs.  Even if I wrote two
additional functions (in plain XLST then), that resp. atomizes a
regular sequence (that means it atomizes any item that is a sequence
ref), and "deeply atomizes" a regular sequence (it atomizes any item
that is a sequence ref, recursively):

    <xsl:function name="sref:atomize" as="item()*">
       <xsl:param name="seq" as="item()*"/>
       <xsl:sequence select="
	   for $item in $seq return
	     if ( sref:is-sref($item) ) then
	       sref:sequence($item)
	     else
	       $item"/>
    </xsl:function>

    <xsl:function name="sref:deep-atomize" as="item()*">
       <xsl:param name="seq" as="item()*"/>
       <xsl:sequence select="
	   for $item in $seq return
	     if ( sref:is-sref($item) ) then
	       sref:deep-atomize(sref:sequence($item))
	     else
	       $item"/>
    </xsl:function>

  If we want to be able to select some items anywhere in the whole
structure defined by a sequence and its sub-sequences (represented by
sequence refs), we can write a visit function, that navigate all items
recursively (entering sequence refs as well), using a first-citizen
function to represent the predicate.

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

> >  I think this minimalist API would permit to play with sequence
> > refs.  If another needs show up with experience, we can always
> > augment the API.  For instance, the above operator could be
> > written as:

> >    ex:sequence-from-ref($ref)[...]

> > (of course, other considerations, like performance, could need
> > more specialized functions, but in the first time, maybe those two
> > simple functions are enough?)

> This approach will be useful for an xx:sequence that has a depth of
> only 2.

  See above, I think we do not have the same thing in mind about
dereferencing a sequence ref.  See also the following entry for more
info about how I specified that:

http://fgeorges.blogspot.com/2008/12/fxsl-currying-and-nestable-sequences.html

  Regards,

-- 
Florent Georges
http://www.fgeorges.org/