Re: Extension candidates

On Thu, Dec 11, 2008 at 10:39 AM, Florent Georges <[email protected]> wrote:
>  Hi,
>
>  Michael and Dimitre have just added new extension candidates on
> http://www.fgeorges.org/exslt2-wiki/.  Thank you!  I have a few
> questions about them...
>
>> * xx:node-ref() - for any node produce a value, which can be
>>   used to obtain this node (node reference)
>
>> * xx:node-from-ref() - navigate to (select) a node from its node
>>   reference
>
>  By "value," do you mean "atomic value"?  I am not sure to see
> exactly the purpose, would you have a sample use case?

Yes, this is just terminology. I see this as a "handle" or "UID". Even
the string returned by generate-id() may do.

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

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

For now, one general approach is to extend xx:evaluate() to include
XPath operations on xx:sequence-s.

>
>  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 do think this is a very important feature.  Here is what I
> have in mind.  The goal is to be able to nest sequences.  Nesting
> sequence means that we want to be able to add a particular
> sequence to another, and that it won't be atomized (as opposed to
> having sequences that wouldn't atomize any other sequences added
> to them.)
>
>  I think the most general, simplest translation of those
> requirements is into two functions, one to transform a sequence to
> "another thing" (I tend to call them "sequence references," but
> one can have better wording,) and one to get the sequence back
> from this object:
>
>    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.

The simplest way to access the Nth component of an xx:sequence is:

   someXXSeq[$N]

The test whether something returned in this way is a sequence can be
as simple as:

  exists(someMaybeSeq[2])

Cheers,
Dimitre