programming XML by Example phần 7 docx

Figures 9.5 and 9.6 illustrate the difference between the two DTDs. Figure 9.5 is the structure created so far—it is a complex structure with several levels of nesting. Figure 9.6, on the other hand, has a flat structure. 303 Writing with Flexibility in Mind Figure 9.5: The default structure Figure 9.6: The new structure Figures 9.7 and 9.8 show the difference when selecting one or the other out- put format in the browser. OUTPUT Figure 9.7: Default output format Figure 9.8: New output format Calling XSLT The major difference between this application and the previous one is the exportProduct() function. exportProduct() calls makeXML() to generate the XML document. Depending on the user choice, it may apply an XSLT style sheet to the result. function exportProduct(form,xml,xslt) { var selected = form.format.selectedIndex, format = form.format.options[selected].value; if(format == “default”) form.output.value = makeXML(); EXAMPLE 11 2429 CH09 11/12/99 1:02 PM Page 303 else { var xmlDoc = makeXML(); xml.async = false; // passes an XML string to the parser xml.loadXML(xmlDoc); form.output.value = xml.transformNode(xslt.XMLDocument); } } Unfortunately, the DOM standard does not specify how to apply an XSLT style sheet to a document. Again, you can use a browser-specific extension. For Internet Explorer, the XSL processor is called by the transformNode() method. The XSLT style sheet was loaded in a separate XML island. <xml id=”xml”></xml> <xml id=”xslt” src=”convert.xsl”></xml> Which Structure for the Document? If your application supports several DTDs, you may wonder which one to use as the default DTD. Experience shows that it pays to be dumb when designing this default DTD. I like to define a DTD that is very similar to my object structure. So, if the application has Product and Price objects, I create two elements: product and price. There are two main advantages to designing a DTD that is close to the internal data structure: • It is easy to generate the XML document. • The resulting document is as expressive as the internal data struc- ture. XSLT Versus Custom Functions XSLT has been designed specifically to convert XML documents. It offers a simple solution to cleanly separate the DTD from the application code. This separation of roles offers many advantages: • If the format changes, you don’t have to change your application, only the style sheet. 304 Chapter 9: Writing XML 11 2429 CH09 11/12/99 1:02 PM Page 304 • Somebody else can write and maintain the style sheet while you con- centrate on the application; this is a simple solution for separating work in a team. • After the system is in place, it’s easy to provide 5, 10, or 100 style sheets. • Conversely, you can deploy the application with only those few style sheets the users really need. Therefore, the application loads faster. NOTE Work is underway to automate the development of the XSLT style sheet. See, for exam- ple, XTransGen from IBM at www.alphaworks.ibm.com. This tool automatically gener- ates the transformation between two documents following different DTDs. What’s Next The next chapter returns to modeling. Armed with a better understanding of how to manipulate XML documents, you see how to create simple and effective DTDs. 305 What's Next 11 2429 CH09 11/12/99 1:02 PM Page 305 12 2429 CH10 2.29.2000 2:24 PM Page 306 10 Modeling for Flexibility You are reaching the end of your tour of XML. In the previous chapters, you learned not only the XML syntax but also how to manipulate XML. The next two chapters are devoted to a real-life e-commerce application based on XML. In this chapter, you review some aspects of XML flexibility. In particular, you revisit some concepts related to modeling documents. I hope the previ- ous chapters have convinced you that XML is a flexible solution for many applications. You have already learned some of these topics in other chapters. This dis- cussion consolidates previous discussions. More specifically, you learn • how to take advantage of XML extensibility through XSL and other standards • about some standards under development by the W3C • about warning signs that may point to problems in an XML document • about the raging debate in the XML community: to attribute or to ele- ment? Structured and Extensible As you learned in Chapter 1 and as you saw demonstrated in Chapters 2 through 9, XML focuses on the structure of documents. Unlike HTML, XML encourages you to focus on the structure of the information. How you even- tually use the document is derived from the structure. For example, presen- tation is derived from the structure. To support the structure, XML is extensible. In practice, it means that you can define your own elements, tags, and attributes and decide how to com- bine them. 12 2429 CH10 2.29.2000 2:24 PM Page 307 The challenge of making a successful XML application is to channel XML extensibility in a positive way. There are two approaches to this challenge, each with its own advantages and disadvantages: • Limit XML extensibility. • Build on XML extensibility as an essential part of the application. This is the first choice to make when considering a new application. Where should you limit XML extensibility or should you build it as an essential part of the application? This chapter illustrates both cases. Limiting XML Extensibility 1. One of the first popular applications on intranets was the address book, and for a good reason. In a large organization, people change jobs very often, or they simply move to another office. Therefore, the phone list is rarely up-to-date. In some organizations, it would require printing a new list every morning, which might not be an option when the list is large. By putting the information on an intranet, the maintenance and the distri- bution of the list are simplified dramatically. To update the list, one simply publishes a new version. And because it is Web-based, the new list is instantaneously available to everybody. To build such a list with XML, you can create a document similar to Listing 10.1. Listing 10.1: A Phone List in XML <?xml version=”1.0”?> <phonelist> <person> <fname>Bill</fname><lname>Allen</lname> <extension>103</extension> <email>ballen@emailaholic.com</email> </person> <person> <fname>John</fname><lname>Doe</lname> <extension>101</extension> <email>jdoe@emailaholic.com</email> </person> <person> <fname>Peter</fname><lname>Fill</lname> <extension>105</extension> 308 Chapter 10: Modeling for Flexibility EXAMPLE 12 2429 CH10 2.29.2000 2:24 PM Page 308 <email>pfill@emailaholic.com</email> </person> <person> <fname>Tim</fname><lname>Martin</lname> <extension>104</extension> <email>tmartin@emailaholic.com</email> </person> <person> <fname>Jack</fname><lname>Smith</lname> <extension>102</extension> <email>jsmith@emailaholic.com</email> </person> </phonelist> You publish the list using the same techniques used in Chapter 5, “XSL Transformation,” to publish the newsletter. Listing 10.2 illustrates what the style sheet might look like. Listing 10.2: The Style Sheet for the Phone List <?xml version=”1.0”?> <xsl:stylesheet xmlns:xsl=”http://www.w3.org/1999/XSL/Transform/” xmlns=”http://www.w3.org/TR/REC-html40”> <xsl:output method=”html”/> <xsl:template match=”/”> <HTML><HEAD><TITLE>Phone List</TITLE></HEAD> <H1>Phone List:</H1> <UL><xsl:for-each select=”phonelist/person”> <LI><A><xsl:attribute name=”HREF”>mailto:<xsl:value-of select=”email”/> </xsl:attribute><FONT SIZE=”+1”> <xsl:value-of select=”fname”/><xsl:text> </xsl:text> <xsl:value-of select=”lname”/></FONT></A><BR/> Extension: <xsl:value-of select=”extension”/></LI> </xsl:for-each></UL> <P>Please help us maintain the list, <A HREF=”mailto:jdoe@emailaholic.com”>email me</A> if you move!</P> 309 Structured and Extensible continues 12 2429 CH10 2.29.2000 2:24 PM Page 309 </HTML> </xsl:template> </xsl:stylesheet> You invoke LotusXSL as in Chapter 5 with the command: java –classpath ➥c:\lotusxsl\xerces.jar;c:\lotusxsl\lotusxsl.jar ➥com.lotus.xsl.Process ➥-in phonelist.xml ➥-xsl phonelist.xsl -out phonelist.html –html The result, in a browser, is shown in Figure 10.1. 310 Chapter 10: Modeling for Flexibility Listing 10.2: continued EXAMPLE Figure 10.1: The phone list in a browser 2. You might want to publish the same list on your organization’s Web site. The list is not only available internally but also externally. However, to limit attacks by spammers, many organizations choose not to publish email addresses. Therefore, you would use a different style sheet, such as the one shown in Listing 10.3. Listing 10.3: Alternate Style Sheet <?xml version=”1.0”?> <xsl:stylesheet EXAMPLE 12 2429 CH10 2.29.2000 2:24 PM Page 310 xmlns:xsl=”http://www.w3.org/1999/XSL/Transform/” xmlns=”http://www.w3.org/TR/REC-html40”> <xsl:output method=”html”/> <xsl:template match=”/”> <HTML><HEAD><TITLE>Phone List</TITLE></HEAD> <H1>Phone List</H1> <P>Here are the direct numbers of our collaborators:</P> <UL><xsl:for-each select=”phonelist/person”> <LI><FONT SIZE=”+1”> <xsl:value-of select=”fname”/><xsl:text> </xsl:text> <xsl:value-of select=”lname”/></FONT><BR/> Tel.: 513-744-8<xsl:value-of select=”extension”/></LI> </xsl:for-each></UL> </HTML> </xsl:template> </xsl:stylesheet> Figure 10.2 shows the result of applying this style sheet. 311 Structured and Extensible OUTPUT Figure 10.2: The new list in a browser 12 2429 CH10 2.29.2000 2:24 PM Page 311 This simple example shows some of the benefits of maintaining the phone list in XML: • The same document can be reused in different contexts; in this case, internal and external phone lists are produced with minimal effort. • It is easy to change the presentation—just update the style sheet. • Although not illustrated in the example, it is easy to maintain the list using an off-the-shelf XML editor. • As the list grows and special needs arise, it is possible to write special- ized software (using DOM or SAX) to further manipulate the list. • If the list grows dramatically, it is possible to move to an XML data- base for better performance. In other words, XML offers a high-quality off-the-shelf software application that you can use to solve a problem quickly and inexpensively. The phone list is a perfect example of an application that does not need XML extensibility. The application is built around a specific DTD and the structure is not expected to change much for the life of the application. The phone list is typical of most XML applications. To work, it greatly lim- its XML flexibility: A DTD is defined and data is made to fit it. It would not make sense for somebody to extend the list in any way. Building on XML Extensibility 1. Some applications need a more flexible solution than used in the pre- vious example. In particular, it might be impossible (or very difficult) to create one DTD for all the data. This is particularly true when sev- eral organizations exchange information. Let’s revisit the price comparison application from Chapter 8, “Alternative API: SAX.” You will remember that the application finds the best price in an XML document such as the one shown in Listing 10.4. Listing 10.4: A Price List in XML <?xml version=”1.0”?> <product> <name>XML Training</name> <vendor> <name>Playfield Training</name> <price delivery=”5”>999.00</price> <price delivery=”15”>899.00</price> </vendor> <vendor> 312 Chapter 10: Modeling for Flexibility EXAMPLE 12 2429 CH10 2.29.2000 2:24 PM Page 312 [...]... preliminary stage There is not even a draft standard, but the following example shows how XML signatures might look This example is taken from Digital Signatures for XML by Richard D Brown Listing 10.14: Digital Signature in an XML Document < ?xml version=’1.0’?> ... elements Listing 10.9: XMLi Style Sheet < ?xml version=”1.0”?> Listing 10.10: WriteIT Style Sheet < ?xml version=”1.0”?> 331... XMLi is a specialist for XML training Our staff has extensive practical experience WriteIT continues 12 2429 CH10 316 2.29.2000 2:24 PM Page 316 Chapter 10: Modeling for Flexibility Listing 10 .7: continued 79 9.00 899.00 ... Sheets < ?xml version=”1.0”?> OUTPUT Copy the XML file from Listing 10 .7 in... that makes sense for you There are many other aspects to XML/ EDI However, it is clear that XML and EDI have a long way to go together In 19 97, I helped cofounding the XML/ EDI Group If you are interested in this topic, I encourage you to visit our Web site at www.xmledi.com XLink Previous chapters have looked at some of the so-called companion XML standards such as XSL, CSS, DOM, and SAX There are others... Playfield Training It is concerned only with Playfield’s elements Listing 10.8: Playfield Style Sheet < ?xml version=”1.0”?> Contact: ... the Web site EXAMPLE Traditionally (without XML) , this would require a fixed template that the merchants would need to fill in For example, they could include their address or other useful information The fixed template would look like Listing 10.5 However, you can do better thanks to XML s flexibility Listing 10.5: Price List with Merchant Information < ?xml version=”1.0”?> XML Training... Merchant-Specific Information < ?xml version=”1.0”?> XML Training Playfield Training 999.00 899.00 John Doe 513 -74 4-8889 jdoe@playfield.com XMLi . makeXML(); EXAMPLE 11 2429 CH09 11/12/99 1:02 PM Page 303 else { var xmlDoc = makeXML(); xml. async = false; // passes an XML string to the parser xml. loadXML(xmlDoc); form.output.value = xml. transformNode(xslt.XMLDocument); } } Unfortunately,. processor is called by the transformNode() method. The XSLT style sheet was loaded in a separate XML island. < ;xml id= xml >< /xml& gt; < ;xml id=”xslt” src=”convert.xsl”>< /xml& gt; Which. elements. Listing 10.9: XMLi Style Sheet < ?xml version=”1.0”?> <xsl:stylesheet xmlns:xi=”http://www.xmli.com/vendor/1.5” xmlns:xsl=”http://www.w3.org/1999/XSL/Transform/” xmlns=”http://www.w3.org/TR/REC-html40” > <xsl:template