Re: Complex XSL Application (I think)

[Mark]
> There's nothing wrong with processing 1.6Gb files, it's just that you
> don't want to do it every time someone wants to display a page! I
> suggest you process it - but only in order to split it up!
[Wendy]
Yes this is great this is something i need to do.
But how do I use XSL to process the large 1.6 gig file into
160,000 smaller files.
> Ultimately this problem has to be a database solution, but given your
> comments on legacy systems, for now:
> 
> 1. Split the 1.6Gb file into a file for each person. If you can generate
> it again this way from the legacy system then that would be quicker,
> otherwise run XSL on the file to get the smaller files.
> 
> 2. Run XSL on the file again to create a much smaller file that
> 'indexes' into these new files. Each node would have the security ID,
> person's name and the file-name of the employee XML file.
> 
> 3. If possible place this data into a database for a nice fast search.
> Sure, its not the full data, but it gives you a quick way in.
> 
> 4. If not possible, then you could search it server-side with XSL,
> although it is still going to be a fair size. (Even better, index this
> file with an indexing server.)
> 
> 5. Generate HTML from the server to the user, for each employee, as
> requested.
> 
> I think this last point is quite important, and I agree with James's
> comments on this. It is still proof of concept to do this, because you
> have generated thousands of pages very easily. However, if that was all
> you did, it wouldn't look that different to what you could do with ASP
> or some such. But ... if you add to the stylesheet clever processing of
> other bits of an employee's XML file, such as a pointer to their manager
> (I assume it's in there if you have 10k on each person!), or their
> department, or something. That really does show the advantage of XSL.
> Creating HTML links to other data from what is a data connection is
> impressive stuff, and makes for a very easy to maintain system; all you
> do is add a little rule to work on a database object, rather than
> hacking into an ASP file and embedding script inside a load of HTML.
> 
> Another little feature to add would be a couple of icons on the HTML
> version of the employee page for things like 'view printable version of
> this employee's details', and 'email these details'. This neatly shows
> the advantages of using different stylesheets.
> 
> Of course, in the future you could deliver that XML to the desktop, but
> for now I think you - and those looking to you for their proof of
> concept - need to be clear exactly where the real productivity gains are
> going to come from, rather than saying 'here's a great technology, let's
> put it on the desktop'.
> 
> Regards,
> 
> Mark
> 
> 
> 
>  XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list


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