Hello Mr. Kay!
Did you or xslt/xquery WG consider introduction of:
tuples - something like opaque sequences, and
maps - associative containers?
I think these set based constructs fits naturally into xslt/xquery.
Please do not think I just want to put my links on this page, but I rather want to refer to my view of tuple and map:
I've implemened tuple and map approximation for Saxon as java extension functions.
Sources can be found at:
I suspect however that a performance of such implementation is far from perfect, as
tuples and maps may be used very often (almost as often as sequences), and reflection layer bites here.
Is it possible to attach extension functions in more efficient way,
or even integrate this or similar api into Saxon?
It's possible in principle to integrate extension functions more deeply into Saxon by writing your own Extension Function binding mechanism - see Configuration.setExtensionBinder(). (At present you can only replace the way that java: URIs are handled, you can't implement support for other URI schemes; the interface is designed to make this possible in future.) Basically if you subclass JavaExtensionLibrary then you can intercept calls on bind() at compile time and bind the function call to your own Expression object which is then called in the same way as built-in expressions. However, it's a lot of work and I don't think I would recommend it - nearly all the Saxon-supplied extension functions are implemented using the standard reflection approach.
There was a significant push to try and get "sequences of sequences" into the XQuery 1.0 data model and type system, but the WG as a whole felt that it was a step too far. If it had succeeded, it could have formed the basis for some of the features you describe.
The requirements list for XQuery 1.1 mentions "references to nodes" as a requirement; I don't know what will come of this, but I think it's another attempt to get more powerful data structures into the model.
I certainly agree there are cases where more powerful collections and maps could be useful. The challenge is to do this in a way that is XML-friendly, that recognizes that the primary purpose of these languages is to process XML. If you have ideas, please submit them to the WG - there's not much point in doing it here.