Re: About node references

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

I think that if someone does this:

<xsl:function name="x">
  <xsl:variable name="temp">
    <xsl:call-template name="build-tree"/>
  </xsl:variable>
  <xsl:sequence select="ref($temp)"/>
</xsl:function>

and then in the calling application attempts to dereference the ref that was
returned, then the dereferencing should succeed. There are two ways of
ensuring this: (a) ensure that the reference is in a form that the garbage
collector recognizes, so that it can ensure that as long as the reference
exists, so does its referand; (b) if a reference to an object has been
created, keep the object for the duration of the query or transformation.

(b) seems to me to be too crude. I think we need (a), and that means that it
is not possible for the reference to consist of a simple string. It could
consist of some internal object that presents string-like behaviour to the
application, but this would cause confusion in that it wouldn't be clear to
the user when the reference ceases to exist. In particular users would be
tempted to copy the string into the contents of a node, and would fail to
realize that the copy wasn't a recognizable reference.

Michael Kay
http://www.saxonica.com/