Subject: xt limits patterns for extension function results? From: Tom Myers <tom.myers@xxxxxxxxxxxxxxxxxxxxxxxxxxx> Date: Fri, 10 Mar 2000 10:47:34 -0500 |
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
Current Thread |
---|
|
<- Previous | Index | Next -> |
---|---|---|
XSL content skip, Steven Mielnicki | Thread | Performance, Mike Engelhart |
Re: More namespace fun?, David Carlisle | Date | Performance, Mike Engelhart |
Month |