Re: Complex XSL Application (I think)

Subject: Re: Complex XSL Application (I think)
From: "Wendy Cameron" <wendy.cameron@xxxxxxxxx>
Date: Wed, 3 Mar 1999 09:02:39 +1000
Apologies all about the last two emails the email system here is very
archaic and I my control key was stuck so when I pressed enter it sent.

[Mark]
> 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.
[Wendy]
Ok this is fine i need to do this anyway.  But how?
-First step
How do I have a server side XML and XSL processor given
Microsoft has withdrawn MSXSL and MSXML
Is there something currently that I can load on the server and
use to do this type of work.
-Second Step
Within the XSL how do I create new persistant files.

[Mark]
> 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.

[Wendy]
Again this is good I need to do this
But I would prefer to create the index from all the smaller files because
if the data was processed from the system into 160,000 seperate files
I dont have one large file to produce an index from.
So I guess im asking how do I do
load SOMEDRIVE:\*.xml
In an XSL stylesheet

[Mark]
> 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.)

[Wendy]
Like this idea of Index server however there is a problem with what if
the files are on a tape?

[Mark]
> 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.

[Wendy]
Id like to see examples of what your discussing here
Will need to do this i think for general ledger.
The employee data is of employees that have been with QR for 10 years
or more and have all of their leave records in it etc

[Mark]
> 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.

[Wendy]
Yes we want to do this but we are looking for an elegant way to distinguish
the printing format to the screen format without writing two separate
templates
for the two veiws.
Examples are good if you have any



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


Current Thread