> I saw that many people in thi maillist prefer make XSLT tranforms and few
> people use XSP. Why? A couple of reasons why I avoid using XSP: 1) It's more or less proprietary (though that is sort of changing). XSLT can be run with many different application servers. 2) XSLT is functional programming and thus lends itself well to rule based processing. XSP is (mostly) procedural programming and in some ways isn't as well suited for the job of sorting and merging tree nodes. Putting point two differently: XSLT is designed specifically for manipulating XML. Java is a general programming language not at all specialized for handling XML, XSP only partly bridges the gap. My personal approach is to try and write generic XSLT for general tasks: eg. filtering the contents of a XML tree based on the contents of a second tree; merging the attributes of two XML trees with similar node names. I then use these as building blocks to create more specific tasks: filtering an XML tree based on what a user is authorized to see; adding presentation attributes to a nodeset based on the final use of the XML. In this way, I can write XSLT that is driven by XML rules that just about any one can author (and maintain). If I was writing XSP and the business rules changed making similar changes would be (I believe) a much harder process. In our case we have (literally) 1000's of business rules to implement, any of which can change on a weekly basis (such is the nature of clinical trials). So having an easy way to dynamically build up applications based on business rules is important to us. If your application is more static and processing speed is more of an issue then a different architecture may make more sense for you. Somewhat off topic, but a general rule at how to pick a particular way of implementing systems: With any large application it's always a good ideas to first build up a conceptual systems architecture based on business requirements. Then build a logical architecture -- based on both the conceptual architecture, the current state of your business and application specific requirements -- before you pick a physical architecture. Only once you have a physical architecture should you start to match up a physical implementation (detail design) with the physical architecture. I know this sounds like a lot of analysis, but its been shown that if you can hit the target of 1/3 analysis, 1/3 development, 1/3 testing, your project life cycle will be much shorter than if you have other proportions of analysis to development and testing... --------------------------------------------------------------------- Please check that your question has not already been answered in the FAQ before posting. <http://xml.apache.org/cocoon/faq/index.html> To unsubscribe, e-mail: <[EMAIL PROTECTED]> For additional commands, e-mail: <[EMAIL PROTECTED]>
