Re: About node references

> There've been useful discussions around node references objects.
> Let me summarize those, and point out open points.
> 
>   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.


>   2/ Node refs as plain strings vs. undefined item types, regarding
> resource management (I think item()+ wouldn't be so useful anyway, as
> it would atomize if added to another sequence, so I think this is
> really xs:string vs. item().)  I think having a string could be
> challenging regarding resource management: how could a processor
> decide to discard a document if we can have string references to its
> nodes?

The XSLT processor can follow the same garbage collecting policy as it uses for nodes that are dynamically created as part of temporary trees.

For example, if a temporary tree has been created as the content of a certain <xsl:variable/>, when this variable goes out of scope and the containing template has no <xsl:sequence/> or XPath "return" that references a node in this temporary tree, then the temporary tree should be garbage-collected.

Do we need a confirmation from the developers of the three existing XSLT processors that such rules are really in place?

I would greatly value Dr. Kay's opinion.


Cheers, 
Dimitre Novatchev.





________________________________
From: Florent Georges <[email protected]>
To: EXSLT ML <[email protected]>
Sent: Saturday, December 13, 2008 12:26:03 PM
Subject: [exslt] About node references

  EXSLTers,

  There've been useful discussions around node references objects.
Let me summarize those, and point out open points.

  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.

  2/ Node refs as plain strings vs. undefined item types, regarding
resource management (I think item()+ wouldn't be so useful anyway, as
it would atomize if added to another sequence, so I think this is
really xs:string vs. item().)  I think having a string could be
challenging regarding resource management: how could a processor
decide to discard a document if we can have string references to its
nodes?

  Of course we want to specify an extension, but I think good
specifications do take pertinent implementation concerns into account
to be sure the functionality is implementable in a reasonable way...
And I think it could be impossible to implement on processors that use
their own source language's garbage collection to manage the trees's
object life time, or at least to reduce optimization opportunities to
discard unused trees or to stream processing.

  Any thought from implementers?

  Regards,

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




















      
_______________________________________________
exslt mailing list
[email protected]
http://www.exslt.org/list