Need non-presentation-oriented usage scenarios

[Sc...@lotus.com]

I am looking for non-presentation oriented usage scenarios for XSLT and
Xalan.  If you have one, and would be willing to take the time to write it
up, it would be much appreciated... send either privately to me or the
list.

Thanks!

-scott

Re: Need non-presentation-oriented usage scenarios

[John Gentilin <ge...@eyecatching.com>]

Scott,

We use Xalan heavily to produce XML streams which is non presentation
oriented.  I have also been hacking away on a set of XSL style sheets to
reformat XMI files that produce a subset of the original XML that is use to
pass into Fop to produce PDF output. i.e. A Use Case document.

Is any of this useful ??

Also, besides some updated documentation, is there anything that you would
like to see completed in the SQL extension code. We finished integrating the
new version of Xalan (with the SQL Extensions) into our product. We also
utilized streaming mode and preliminary tests shows about a 10-15% speed
increase for simple query modes. I was actually surprised in the increase.

There are few items I am looking into adding but have not assigned a time
frame
to them as of yet.

1) Adding a closeWithCopy() method to reduce the number of open connections.

2) As per M. Kay's book create a set of examples that show summing & grouping
    with streaming mode enabled.

3) To do grouping, you need to have access to at least the previous sibling.
To do this
     I plan to add a method to define the number of row-set nodes to store.
Right now
     with streaming mode disabled, it is as large as the query and with
streaming mode
     it is set to one.

Regards
John G

Scott_Boag@lotus.com wrote:

> I am looking for non-presentation oriented usage scenarios for XSLT and
> Xalan.  If you have one, and would be willing to take the time to write it
> up, it would be much appreciated... send either privately to me or the
> list.
>
> Thanks!
>
> -scott

Re: Need non-presentation-oriented usage scenarios

[everett stauffer <ev...@chem.ucsd.edu>]

Given that I already have a presentation-oriented framework for
doing financial and personnel reporting, it was extremely easy
to set up a nightly batch job to create daily balances that
get stuffed into a database.

I currently have (this is the 3rd month of our fiscal year) a
XML cache of 5000 files (5.6MB).  An additional 3000 files
are dynamically generated and consumed at runtime.  This makes
approximately 8MB of data.  The actual processing is done against
1100 files ('entities') created from the cached and dynamic data and
1100 dynamic data files that are used in the stylesheet via document().
The stylesheet makes heavy use of key() and produces three numeric
values per 'entity'.

Total processing time is currently 21 minutes.  Perhaps as much
as 3 minutes of that time is spent getting data from the database
and creating the 2200 files.  The rest is Xalan.

This "TimerTask" process replaced a TCL job that had took almost
two hours at this time in the year.  I consider this a HUGE gain.
Since I have a JSP page that can access the TimerTask object I
can see the processing time on a per entity basis.  Most entities
take ~1 sec to process.  Those with a large number of nodes can
take a couple of minutes to process.  My informal analysis is
that processing time runs like the square of the nodes, rather
than linear with the number of nodes.

Platform:
Dual 650MHz Intel PII, 256MB RAM
Red Hat Linux 6.2
Sun Java 1.3
Tomcat 3.2.3
Xalan-J 1.2.2

My only 'complaint' to date has to do with the memory consumption.
The use of key() has been very good for performance, but the use
of key() and document() leads to excessive memory usage.  Current
memory consumption for my batch is 50MB.  Towards the end of our
fiscal year it is using 70+MB.  If there isn't a way to explicitly
cause Xalan to dump all key and document caching, there should be.
An alternate method might be to have a 'switch' to enable or disable
caching.  The <?xalan:doc-cache-off?> directive is a nice touch,
but far too limited in where it can be used.  Though where it can be
used, I have seen some memory savings.


Keep up the great work!

Everett


Scott_Boag@lotus.com wrote:
> 
> I am looking for non-presentation oriented usage scenarios for XSLT and
> Xalan.  If you have one, and would be willing to take the time to write it
> up, it would be much appreciated... send either privately to me or the
> list.
> 
> Thanks!
> 
> -scott

RE: Need non-presentation-oriented usage scenarios

[Paul Brown <pr...@fivesight.com>]

Scott --

We use Xalan in quite a few non-presentation oriented scenarios.  The idea
that "XSLT is a tree transformation language" is not my idea, but it's the
truth -- XML (SAX or DOM) is really only an "interface" for accessing
hierarchical information, and XSLT is a way to interpolate between those
interfaces.

With that in mind, we are using XalanJ2 (coupled with a parser description
language that creates SAX event drivers for non-XML files and a serializer
description language, also SAX-based) to transform EDI->EDI (X.12, EDIFACT,
etc.), HL7->HL7 (v2.x to v2.x, v2 to v3, etc.), and we're starting to work
with SWIFT.  For the EDI-EDI, applications, throughput is great: ~5M typical
messages per day on a desktop PC.  To put that in perspective, a typical
large hospital will handle thousands of messages per day.  A medium-sized
VAN will handle 1M message per day.  Considering the variety of tools, IDEs,
mappers, etc. -- XSLT is more than adequate.

The only reason I can think of to use anything else is a bad case of "NIH".

Paul Brown
FiveSight Technologies, Inc.

> -----Original Message-----
> From: Scott_Boag@lotus.com [mailto:Scott_Boag@lotus.com]
> Sent: Wednesday, September 05, 2001 4:09 PM
> To: xalan-dev@xml.apache.org
> Subject: Need non-presentation-oriented usage scenarios
>
>
> I am looking for non-presentation oriented usage scenarios for XSLT and
> Xalan.  If you have one, and would be willing to take the time to write it
> up, it would be much appreciated... send either privately to me or the
> list.
>
> Thanks!
>
> -scott
>
>
>
>