Introduction to XML for Database Developers - XSL
(Page 9 of 9 )
The eXtensible Stylesheet Language (XSL) addresses the need to transform XML documents from one XML form to another and to transform XML documents to other formats such as HTML and WML. It is based on Cascading Style Sheets (CSS), a language for styling HTML documents. Over time, XSL has been transformed into three other languages:
- XSLT for transforming XML documents
- XSLF for rendering
- XPath for accessing a specific part of an XML document
XSLT XSLT is a (new) language for transforming XML documents. W3C gave it Recommended status in November 1999. XSLT style sheet files are also well-formed XML documents. These files are processed by XSLT processors. Such a processor can be a separate tool or part of an XML parser (as in the case of MSXML).
At this point, I will not go into detail about XSL and XSLT syntax. Such topics are really beyond the scope of this book. Refer to www.w3.org/Style/XSL/ and www.w3.org/TR/xslt for more information on this topic. However, I will cover the use of XSLT in SQL Server 2000 later in “Using XSL,” in Chapter 14.
--------------------------------------------------------------------Why XML?
I have described XML, which is all well and fine, but of course the questions arise: why do you need XML, and what can you do with it? Two major areas of application are
- Exchange of information between organizations
- Information publishing
Exchange of Information Between Organizations XML provides platform-independent data transport for a variety of types of information, from simple messages (commands, information requests) to the most complex business documents. Its extensible nature—the ease with which you can add new nodes or branches, create multiple instances of the same element, and use open schemas to add elements as necessary (provided they comply with schema rules)—makes XML an ideal development language for the rapidly evolving “dotcom” economy. You can use XML to implement solutions that can grow and evolve with an organization and be relatively certain that your solution will not end up on next year’s scrap heap and that the organization will not have to replace it at an enormous cost as the needs of the organization grow and change.
It is no wonder that Microsoft has incorporated support for XML in its new releases of applications such as SQL Server, Exchange, Visual Studio, and Internet Explorer. This support allows Microsoft to remain the major player in operating systems and network solutions even as businesses organize themselves into trading communities and industry associations defined by their ability to exchange information seamlessly and securely via the Internet.
EDI: a Cautionary Tale XML is finding extensive application within the B2B (business-to-business) and B2C (business-to-consumer) arenas, to name but two of this young century’s most ubiquitous buzzwords. XML’s success in this emerging marketplace is largely due to its platform independence, which translates directly to the bottom line in terms of low implementation costs. Trading partners require only Internet access and a web browser to conduct secure business transactions over the Internet.
One of the buzzwords of the early 1990s was EDI (Electronic Data Interchange). EDI is still around, but it has never fulfilled its promise to make the exchange of paper documents between businesses obsolete. It was the cost of implementation that prevented EDI from fulfilling this promise. The problem that EDI encountered is a variation on the “Tower of Babel” theme: the proliferation of languages and protocols ensured that each implementation would be unique, and therefore costly.
Classic EDI follows a hub-and-spoke model: a large company (the “hub”) that must manage business relationships with a large number of suppliers (the “spokes”) decrees that the spoke organizations must implement EDI or lose their trading-partner status. The spoke organizations have to bear the considerable cost of implementation or lose a considerable portion of their business income.
A company that is forced to implement EDI by virtue of a trading relationship with a hub company receives an “implementation guide” that describes the EDI standard with which it must comply. One EDI veteran described the difference between classic EDI and XML-based e-commerce succinctly: with EDI, your postal carrier delivers an implementation guide printed on paper; with XML-based e-commerce, the implementation guide is attached to the electronic business document/transaction in the form of a DTD or XML schema.
This comparison is a gross oversimplification of the relationship between these two technologies, but it does highlight one reason that XML-based e-commerce has succeeded with small- to medium-sized businesses where EDI could not, and that is its relatively low cost of implementation.
The other reason for this success is that XML-based e-commerce leverages Internet-based communications. The dial-up Value Added Networks (VANs) of the EDI world are more or less glorified (and generally expensive) electronic mailboxes to which you post business documents and from which you download business documents from your trading partners. The XML revolution has spawned Internet-based, third-party Application Service Providers (ASPs) and “Infomediaries” to take the place of the VANs and use XML to conduct business transactions between diverse trading partners.
Of course, these ASPs and Infomediaries are in the business of developing data-based applications for the Web, so you can begin to see why it is so important that SQL Server be XML-ready. The new XML features in SQL Server 2000, along with SQL Server’s ease of use, make it a leader in this emerging market.
Information Publishing Just as trading partners can use XML to exchange business documents, organizations and individuals can use XML to develop data-based applications that publish information. The only real difference between business document exchange and information publishing is that the information itself becomes the commodity.
Using XML to publish information located in a SQL Server database combines the easy access of the Internet with the power and data integrity of a mature RDBMS. Browser-based applications allow users to retrieve data dynamically from diverse databases.
| DISCLAIMER: The content provided in this article is not warranted or guaranteed by Developer Shed, Inc. The content provided is intended for entertainment and/or educational purposes in order to introduce to the reader key ideas, concepts, and/or product reviews. As such it is incumbent upon the reader to employ real-world tactics for security and implementation of best practices. We are not liable for any negative consequences that may result from implementing any information covered in our articles or tutorials. If this is a hardware review, it is not recommended to open and/or modify your hardware. |
|
 This article was excerpted from chapter 13 of SQL Server 2000 Stored Procedure & XML Programming, second edition, written by Dejan Sunderic (McGraw-Hill/Osborne, 2004; ISBN: 0072228962). Check it out at your favorite bookstore today. Buy this book now.
|
|
/ 8 
