Lists Home |
Date Index |
- To: email@example.com
- Subject: Re: [xml-dev] RE: Incremental transformations with Xalan and performance issues?
- From: Marian Olteanu <firstname.lastname@example.org>
- Date: Sat, 4 Dec 2004 23:55:18 -0800 (PST)
- Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys
- Domainkey-signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; b=GENu1gM96FzPhLSEXQHS0UhlL2f+cFO+7E3Nj32HIGbP6RiFA25ub9imm+GDmX8UFgQe6sV3OGrzK4C1gI5H89K3hlaCLKvuwvUFrsGaYkNQ3Sb+EtDCAQAERZ4zSYwTr/aMQeWqX9cihsYPgE+x5FRxkb3NsRxgnl2iFIXyXJI= ;
- In-reply-to: <41B1BE2D.26184.12911917@localhost>
> Do you happen to know if anyone has tried to build an XSLT engine that does
> incremental transformations on incoming SAX events, without requiring the
> building of a tree? That kind of approach, where the transform is
> appropriate, would be much more efficient in memory useage and would allow
> transforms of virtually unlimited size documents I should think. Something
> to investigate...
Now you're trying to bind yourself to the XSLT processor implementation, which in my oppinion is
the worst thing you can do.
I understand that at least you can design the structure of the XML documents. Considering this,
your options are:
1. live with the fact that your system can be extremely slow
- advantage: you don't need to do anything
- disadvantage: your solution is at least not scalable; worst case: it might not be usable at
2. split your data through different XML files
- advantage: it will work, with a proper design
- disadvantage: it is harder/annoying to manipulate more than one file. If you are not careful
in designing your solution, you will end up loading all files in one transformation step.
3. find the desired XSLT processor.
- advantage: it will solve your solution cheap
- disadvantage: probably you won't find it anyway. Still it will not work if you don't carefully
desing the structure of the XML. You will be tightly bound to the XSLT processor
Do you Yahoo!?
The all-new My Yahoo! - What will yours do?