[XSL-LIST Mailing List Archive Home] [By Thread] [By Date]

Re: [xsl] How should I structure a huge XSLT dataset best?

---

---

----- Original Message ----- 
From: "Kevin Jones" <kjones@xxxxxxxxxxx>
To: <xsl-list@xxxxxxxxxxxxxxxxxxxxxx>
Sent: Tuesday, September 30, 2003 11:22 AM
Subject: Re: [xsl] How should I structure a huge XSLT dataset best?


> On Monday 29 September 2003 21:32, Anthony Zawacki wrote:
> > The lack of obvious precendence for this type of work makes it
> > much more difficult.  I'm used to being able to search the
> > list or looking at the XSLT FAQ and seeing easy solutions, but
> > this type of issue doesn't seem to have been addressed in the
> > past.  Or am I missing something?
> 
> We have a client that has a similar setup, large data sets 
> contained in the stylesheet. They typically store the data in a 
> variable and access it directly from there. The problem with 
> this approach is that the processor will normally bind the 
> variable to this data by creating a result tree fragment from 
> its contents at runtime. For large data sets this can be 
> expensive. Our processor can recognise if the variable content 
> is constant and if so it effectively binds the variable at 
> compile time eliminating this problem.
> 
> A more general solution is to just put your data in the 
> stylesheet as a child of the <xsl:stylesheet> under a different 
> namespace. In which case you can access it via a 
> document('')/xsl:stylesheet/mydata:data type XPath. If the data 
> is to be imported from a second stylesheet you would need to use 
> its name in the document() function. The performance of this 
> technique relies on the processor keeping the stylesheet object 
> model(s) in memory after compilation and recognising that you 
> are referring to the same document. This is not always true but 
> most processors appear to work that way.
> 
> As to the structure of your data, is this not a search problem a 
> trie is ideally suited to. If this is the case you may be able 
> to generate XSLT to perform the search directly without the need 
> for a data table. Trie's can be encoded into a set of nested 
> switch statements triggering on each character in the test 
> string. This is most likely the quickest solution and avoids the 
> issues of the other options above.
> 
> Regards,
> Kev.
> 
> 
> 
> 
> 
> 
http://www.balancedinterface.com 


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

---