| home / authoring / languages / xml / xsltdev / chap12 / 2 | [previous] |
|
Who is my intended audience, and which clients do I need to support? Perhaps XSLT is a very good fit to solve your current problem. However, you will need to consider whether your intended audience is ready for its use. For example, if you decide to use client-side XSLT extensively for your application, you will want to make sure that your audience uses XSLT-enabled browsers. This issue gets particularly tricky if you decide to build presentation-independent applications that will be accessed from channels such as wireless phones and PDAs. As far as we know, none of the widely deployed WAP microbrowsers currently support XSLT. In such a case, you will want to use server-side XSLT, generate WML, and provide it for the benefit of the WAP clients. Hence, think carefully about using XSLT client side versus server side, and think about whether this decision can be made conditional within your application logic. Also consider performance issues. For example, if you are carrying out extensive XSLT transformations, does it make sense to defer the transformation load to the client side, or will you serve your audience better by performing the transformations on the server side.
Which other technologies will be a part of the solution: for example, RDBMS, Java, and so on? Large RDBMS vendors such as Oracle, IBM, and Microsoft provide very good support for XML: that is, the process for extracting the data in an XML form or inserting data from XML files into a database is quite straightforward. Languages such as Java and Perl also work very well with XSLT, and entire volumes have been devoted to address such use of XSLT.
Is someone in my industry, either an individual company or a consortium, already addressing this problem? Before embarking on an extensive (and expensive!) XML/XSLT undertaking, you will be well-advised to do research around this question. Perhaps a trade magazine has published an article related to a similar business problem that you could learn from. Perhaps your competitors have addressed similar problems and have published case studies or discussed their undertakings at a conference. You could learn valuable lessons from any difficulties that they may have came across and any workarounds that they may have found, and certainly you can avoid any mistakes they may have made. Perhaps a consortium is working on finalizing a standard specific to your industry. If this is the case, you might be better off waiting until this standard is finalized and then leveraging it for a quicker implementation that will also work better when interfacing with your customers and suppliers. Such research could help you avoid costly and time-consuming mistakes in your implementation. It will also help you create a more robust and longer-lasting implementation.
By no means is the list of issues provided here exhaustive. However, we ourselves have come across such issues over and over again, and therefore we hope that addressing these questions will be a good starting point for you.
In this chapter, we considered practical issues related to the development of applications that use XSLT. We discussed how XSLT is useful in solving problems related to content syndication, B2B, and EAI. We also discussed the state of the art of client-side support for XSLT and ways to build presentation-independent applications that can be accessed by clients of differing types.
Armed with this knowledge, you should now be well-prepared to benefit from the next chapter, which discusses a variety of XML and XSLT tools, as well as the technologies that complement XSLT.
| home / authoring / languages / xml / xsltdev / chap12 / 2 | [previous] |
Created: June 3, 2002
Revised: June 3, 2002
URL: http://webreference.com/authoring/languages/xml/xsltdev/chap12/2/4.html