Re: [xsl] XSLT 2.1: Nestable sequences or sequence references?

["Dimitre Novatchev" <dnovatchev@xxxxxxxxx>]

On Mon, Dec 8, 2008 at 2:05 AM, Michael Kay <mike@xxxxxxxxxxxx> wrote:
> I think there are quite a few people who recognize that there's a need for
> richer data structures in XDM, but there are different views about how
> important such features are, and about exactly what features should be
> provided to meet the requirement. (The cited bugzilla entry, you will
> notice, is marked "closed, won't fix", but that doesn't mean that all
> progress in this general area is ruled out.) Ideas include
>
> (a) nested sequences
>
> (b) references (an item can be a reference to a node or any other value)
>
> (c) tuples whose fields are known and named at compile-time
>
> (d) maps whose keys are known only at run-time
>
> (e) higher-order functions (which would enable any of the above to be
> constructed, though perhaps not with elegant syntax)

(a) and (b) are extremely needed if we want to be able to compare XSLT
with true programming languages.

As I am tired of asking for (a) and learning from all prior
experience, I absolutely don't have any illusions these will be part
even of XSLT 4.

Therefore, Isn't it high time for *EXSLT 2*?

To the list of *nested sequences* and *references* I would also add
*memoisation*.

we need something quite simple, and very easy to implement:

     type:reference   nodeRef(node)

     node   fromRef(reference)

   the @memo-function attribute as already implemented in Saxon.

We could even accept that generate-id() is our nodeRef(), so we'd need
just the last two functions.

Florent has written his Java implementation and it is a matter of days
for a C# implementation of something similar ...  :( to surface out...
By not standardizing we will very soon find ourselves with a number of
incompatible definitions of such functions and will have to face all
the resulting portability issues.

Let's be realistic and pragmatic and not wait in the next ten years
for a committee blessing. We have EXSLT and EXSLT has worked well in
the past and served real needs.

I appeal to the EXSLT community to respond and provide the definitions
of the above three features -- in the name of the ideas this movement
(I still believe) stands for.

Cheers,
Dimitre Novatchev.



>
> By all means add your own input to the WGs; it's harder to dismiss a
> requirement if there's evidence of widespread support for it. Practical use
> cases of things you can't do (easily or efficiently) today are always the
> most persuasive argument.
>
> Michael Kay
> http://www.saxonica.com/
>
>> -----Original Message-----
>> From: Florent Georges [mailto:lists@xxxxxxxxxxxx]
>> Sent: 08 December 2008 01:05
>> To: XSL Mulberry list
>> Subject: [xsl] XSLT 2.1: Nestable sequences or sequence references?
>>
>>   Hi,
>>
>>   I've digged a bit into the W3C bugzilla, but didn't find
>> anything.  Is there any plan to introduce some kind of
>> nestable sequences or sequence references in XPath or XSLT 2.1?
>>
>>   By nestable sequence, I mean a kind of sequence that is not
>> automatically atomized.  For instance:
>>
>>     sref:make-sref((1, 2)), sref:make-sref((3, 4))
>>
>> would be (pseudo-code):
>>
>>     ( (1, 2) (3, 4) )
>>
>> that is, a sequence of two sequences (of each two integers.)
>>
>>   Regards,
>>
>> --
>> Florent Georges
>> http://www.fgeorges.org/
>
>



-- 
Cheers,
Dimitre Novatchev
---------------------------------------
Truly great madness cannot be achieved without significant intelligence.
---------------------------------------
To invent, you need a good imagination and a pile of junk
-------------------------------------
Never fight an inanimate object
-------------------------------------
You've achieved success in your field when you don't know whether what
you're doing is work or play