xt limits patterns for extension function results?

[Tom Myers <tom.myers@xxxxxxxxxxxxxxxxxxxxxxxxxxx>]

I'm using xt extension functions to generate NodeIterators
which I then process within the stylesheet; it works. 
However, the patterns acceptable for matching the results
are restricted, and I wondered if anybody who has done
this has a notion as to why.

For example, suppose I have a simple document, SampleRow.xml,

<dummy>
  <row>  <field name='Zip'>13346</field>
  <field name='RecTime'>13:40 PM </field>
  <field name='Temp'>37</field>
  <field name='DayLo'>35 </field>
  <field name='DayHi'>46 </field>
....
and so on; a query output representable as a single database row.
Within a stylesheet, I can now say

  <xsl:variable name="docrows" select="document('SampleRow.xml')/*"/>
and the document has been read in;
 <xsl:value-of select="$docrows/row/field[@name='Temp']" />  
is of course 37. If I wanted to write a maximally unreadable
equivalent for "$docrows/row/field[@name='Temp']" I might say

  "$docrows/*[name(.)='row']/*[name(.)='field'][@*='Temp']"

and it would work, as long as each 'field' has only one attribute,
which it does.  Now it happens that I don't want to generate
docrows by reading in an actual file, I want to do it by generating
a NodeIterator:

 <xsl:variable name="rows" select="vdoc:query-result($theSessionID)"/> 

and that's fine...I define queryResult(String sessionID) to return
a NodeIterator, and now I can get the temperature with 

 <xsl:value-of select="$rows/*[name(.)='field'][@*='Temp']" />

(note that we're one level lower down on the corresponding tree.) In
other words, I can use the maximally ugly syntax, but not the natural
syntax that makes XSL reasonably good to use.

Anybody have a thought on what's going on here?
 

Tom Myers 




 XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list