Re: About node references

> 
> Dimitre Novatchev wrote:
> 
> > >  1/ I still fail to see use cases that node refs would help
> > > solving, if we had sequence refs (or nested sequences.)  If
> > > node refs are plain strings, I understand they could be added
> > > to an XML tree, but I can't see what that could solve that
> > > nested sequences couldn't.
> 
> > Why, the Use Case we started with was Christopher Lange's problem
> > with currying. Its solution is to save a node reference when
> > currying and to deref it when all necessary additional arguments
> > have been passed and the function should finally be evaluated.
> 
>   Yes, but that could be achieved with nested sequences, couldn't
> it?

Sorry, I don't see even the slightest connection ?  The original problem is curring a node, not a sequence.

>  If I am right, we have the following ideas for now:
> 
>   1/ nested sequences: the ability to create more complex structure
> that the "flat sequences" in standard XPath 2.0, using sequence
> references; those refs are of a specific type, and cannot be added
> to a tree;
> 
>   2/ node refs, NOT implemented as strings: IMHO a specific case of
> idea 1/;
> 
>   3/ node refs, implemented as strings: could be added to a tree,
> and then dereferenced later (with garbage collection potential
> issues.)
> 
>   If I am right, you are thinking about 3/ above with currying,
> while I think this could be solved also by 1/.  

I never even considered 3/

There shouldn't be two separate approaches for 1/ and 2/

Both 1/ and 2/ request that we have just "reference" and it is not important if the reference is to a sequence or to a node. Remember that any node is in fact a sequence of just one item.

Therefore, we should have just a single "ref" type.  It can be a ref to an instance of any other "non-value type". 

A value type is (like in .NET) any simple atomic type, like xs:integer or xs:string. I used to call these "scalar types" -- types without structure. Probably we can define this more precisely.

Cheers,
Dimitre