OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

 


 

   Re: [xml-dev] Parallel tree traversal

[ Lists Home | Date Index | Thread Index ]

Hi Peter, [responses/questions inline]

Hunsberger, Peter wrote:

> 
> There are many attributes on each element giving various pieces of
> metadata, and in particular for this case, determining how a particular
> node gets presented in the menu. For a given metadata structure we need
> to map many possible data items, eg:
> 
> <data>
> 	<a id="1"/>
> 	<b id="2" idref="1"/>
> 	<c id="3" idref="2/>
> 	<d id="4" idref="3"/>
> 	<e id="5" idref="4"/>
> 	<e id="6" idref="4"/>
> 	<c id="7" idref="2/>
> 	<f id="8" idref="1"/>
> 	<a id="9"/>
> 	<b id="10" idref="9"/>
> 		...
> </data>
> 
> Any given metadata node may not have any data associated with it.  If it
> does, it must have a parent data item.  Using the data structure I can
> determine that, in this, case I have to present a menu that has a
> structure like:
> 
> <menu>
> 	<a id="1">
> 		<b id="2">
> 			<c id="3"/>
> 				<d id="4">
> 					<e id="5"/>
> 					<e id="6"/>
> 				</d>
> 			</c>
> 			<c id="7"/>
> 		</b>
> 		<f id="8"/>
> 	</a>
> 	<a id="9">
> 		<b id="10">
> 		...
> 	</a>
> </menu>
> 
> The current strategy is to track the current id and pass it to a
> recursive XSLT template selecting all the data nodes that have an idref
> that is equal.  


You could create a key based on the idref attribute:

<xsl:key name="idrefs" match="*" use="@idref"/>

and apply templates on the matches from something like:

<xsl:variable
   name="focus_children"
   select="key('idrefs', $focus_idref)"/>

<xsl:apply-templates match="$focus_children"/>

Does this solve your problem (needing a nodeset function)?


> 
> It turns out that it would be easy to generate the tree structure for
> the data directly.  However, I can't just use it directly, since if
> there is a missing data item I may still have to insert a menu item to
> create a new instance (depending on the metadata).  


I am not understanding this. Are you trying to do all operations on the 
flat structure or are you first transforming to the hierarchy? What is 
the difference between inserting a missing menu item in the hierarchy 
versus the flat structure? I guess I don't understand why you would not 
keep this in a hierarchy to begin with (are you doing other things not 
explained here?).

Before i comment further I would need to understand this.

best,
-Rob

p.s. didn't we talk about this on cocoon-dev a few years ago? :)


> So, I need to track
> the metadata as well. This is conceptually easy, just select the
> children of the current element and recursively pass it on to the
> template.  However, practically, this is expensive in XSLT 1.0 since to
> subsequently use a parameter created in this manner it appears you have
> to use the nodeset function.  Eg:
> 
> 	<xsl:apply-templates select="*" mode="menu">
>       	<xsl:with-param name="data" select="exslt:nodeset($data)/*"/>
> 	</xsl:apply-templates>
> 
> Now, in this particular case we are using Saxon, so this raises two
> specific questions: 1) if I just declare the transform to be XSLT 1.1
> and skip using the nodeset function will I see any performance gains?
> 2) Would using Saxon 7 and XSLT 2 have any performance gains?
> 
> A more general question is whether anyone sees any other strategy for
> managing the above, or whether anyone has any opinions on which approach
> should work better?  I can tell you that experiments with the second
> approach traversing the metadata and passing the data as a parameter
> seem to exhaust memory for large data trees though it works fine for
> smaller trees. I'm about to see if I can do the inverse from the above
> example: parse the data and pass the metadata as a parameter, but this
> is a non-trivial transform (lots of metadata affecting many things) so I
> thought I'd check first if anyone has a definite opinion about which way
> to proceed.
> 
> Peter Hunsberger





 

News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 2001 XML.org. This site is hosted by OASIS