RE: Complex XSL Application (I think)

Subject: RE: Complex XSL Application (I think)
From: Mark Birbeck <Mark.Birbeck@xxxxxxxxxxxxx>
Date: Thu, 25 Feb 1999 12:34:24 -0000
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!

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

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'.



 XSL-List info and archive:

Current Thread