XML and Related Technologies certification prep,Part 5: XML testing and tuningDiscover tools and hints for working with XML
Skill Level: Intermediate
Louis E Mauget ([email protected])Senior ConsultantNumber Six Software, Inc.
24 Oct 2006
This tutorial on XML testing and tuning is the final tutorial in a series that helps youprepare for the IBM certification Test 142, XML and Related Technologies. Thistutorial provides tips and hints for how to choose an appropriate XML technology andoptimize transformations. It wraps up with coverage of common tools you can use intesting XML designs.
Section 1. Before you start
In this section, you'll find out what to expect from this tutorial and how to get themost out of it.
About this series
This series of five tutorials helps you prepare to take the IBM certification Test 142,XML and Related Technologies, to attain the IBM Certified Solution Developer - XMLand Related Technologies certification. This certification identifies anintermediate-level developer who designs and implements applications that makeuse of XML and related technologies such as XML Schema, Extensible StylesheetLanguage Transformation (XSLT), and XPath. This developer has a strongunderstanding of XML fundamentals; has knowledge of XML concepts and relatedtechnologies; understands how data relates to XML, in particular with issuesassociated with information modeling, XML processing, XML rendering, and Webservices; has a thorough knowledge of core XML-related World Wide Web
Consortium (W3C) recommendations; and is familiar with well-known, bestpractices.
About this tutorial
This tutorial is for programmers who have a basic understanding of XML and whoseskills and experience are at a beginning-to-intermediate level. You should have ageneral familiarity with defining, validating, and reading XML.
The standardized nature of XML has given rise to a number of derivativecross-platform, cross-language parsers and derivative technologies. Parts 1 through4 of this series discussed applied aspects of XML and its common relatedtechnologies (see Resources). To wrap up the series, this tutorial presents a numberof rationales and hints for choosing appropriate technologies, explains how simplechoices affect performance, and demonstrates simple examples of how to usecommon tools to test XML designs.
Objectives
After completing this tutorial, you will know how to:
• Choose an appropriate XML technology
• Optimize a transformation
• Test an application of XML
Prerequisites
This tutorial is for developers who have a background in programming or scriptingand who understand basic computer-science models and data structures. Youshould be familiar with the following XML-related, computer-science concepts: treetraversal, recursion, and reuse of data. You should be familiar with Internetstandards and concepts, such as Web browser, client-server, documenting,formatting, e-commerce, and Web applications. Experience in designing andimplementing Java™-based computer applications and working with relationaldatabases is also recommended.
System requirements
This tutorial's testing and demonstration tools -- Internet Explorer® 6.0, MozillaFirefox 1.5, Altova XMLSpy Home Edition, and IBM® Rational® ApplicationDeveloper for WebSphere Software V6.0 -- are all either free, bundled withMicrosoft® Windows®, or available as time-limited free evaluation copies. Procurethem on the Web from the links provided in Resources.
• FireBug: A Firefox browser Document Object Model (DOM) and scriptextension
• XMLBuddy: An XML editor plug-in for the Eclipse integrateddevelopment environment (IDE)
Section 2. Choosing an appropriate XML technology
The following sections discuss choices and trade-offs to consider when choosing anXML technology.
W3CDOM
DOM is a representation of an XML or HTML document as a tree data structure. Amodern DOM parser includes an API and conforms to a series of standardspecifications from the W3C. Such a parser is known as a W3CDOM parser. It isindependent of computer language and platform. Older DOM parsers werevendor-specific and therefore not as portable as today's W3CDOM parsers. Whenthis tutorial refers to a DOM parser or a DOM, it's referring to a W3CDOM. Forcross-platform language independence, it is recommended that you use a standardW3CDOM parser when you work with a DOM.
CRUD
To create a DOM tree, you can use a parser to recognize an XML stream, createnodes and attributes programmatically, or use a combination of each approach. ADOM parser supports full Create, Read, Update, and Delete (CRUD) functionality ofDOM elements. If you use the DOM API, you don't deal with angle brackets andXML syntax when you create or update an XML document. Creating XMLprogrammatically from string data is generally messy and error-prone. You can alsouse XSLT to create an XML document, but it requires a base document. Irecommend that you use a DOM parser API to create or update XML documentswhen not creating or transforming a base XML document to a new document.
Push versus pull
Simple API for XML (SAX) is an XML serial stream parser. A SAX parser applicationuses a data push model, meaning that the parser calls the application when adesired element or attribute appears from the XML input stream. The applicationregisters a callback for each desired SAX event. Compare this push model to the
DOM pull model, where the application pulls desired nodes from a DOM tree.
A SAX-oriented application can handle a huge XML document, limited only by whatit does with the data pushed to it. The application registers callback functions onlyfor nodes or attributes of interest. The other elements are ignored during the parseoperation, so they don't cause a memory-resource drain.
Finite main memory limits a DOM-oriented application, because the DOM parsertransforms the entire document into an in-memory tree. On the other hand, aDOM-oriented application can access XML DOM nodes in any order. Additionally, itcan add, modify, or delete those nodes, as mentioned earlier. A SAX applicationcannot directly modify nodes or access them outside of their natural documentordering.
Dual APIsDOM parsers, such as those of the Apache Xerces family, usuallycreate a DOM tree through an internal SAX parser. These parserscan expose both the DOM API and a SAX API.
You should choose a SAX parser for large read-only documents. If you need randomaccess to DOM nodes, use a DOM parser.
Narrative versus data
XML is a standardized metalanguage used to create custom document grammars. Itowes its roots to Standard Generalized Markup Language (SGML), a complexdocument markup language. Table 1 lists a few characteristics of narrative XMLdocuments.
Table 1. Narrative XMLCharacteristics of narrative XML
Raw source is human-readable and not necessarily pretty
Hierarchical format
Content hierarchy is extremely flexible
Documents can be large
Documents render to human-readable text
The primary actor is a human being
We ate our own dog food in publishing this series of XML developerWorks tutorials.This tutorial document is a raw XML source document that conforms to a strictnarrative XML schema. You're reading the rendered result, transformed by XSL toHTML for the Web rendition, or XSL Formatting Objects (XSL-FO) for the PDFversion.
The standardized nature of XML attracts programmers who need to manipulaterigidly formatted hierarchical data. Today, the application of XML to describe data isubiquitous. Table 2 lists some of the characteristics of XML used to describe data.
Raw source is human-readable and not necessarily pretty
Hierarchical format
Content hierarchy is extremely rigid
Documents are often small but can be large
Documents might not render to human-readable text
The primary actor is a computational process
Table 3 summarizes the differences between Table 1 and Table 2.
Table 3. Narrative versus data XMLDocument type Description
Narrative Flexible, large, acted upon by human beings
Data Rigid, small, acted upon by a computationalprocess
Consider these distinctions when you design a document XML schema or DocumentType Definition (DTD). In fact, your first choice is to choose whether to constrain thedocument by XML schema or by DTD.
XML schema versus DTD
A schema enables fine-grained control over the document format -- something notnormally associated with a narrative form, but often important to a data document.Suppose a document contains a zip code that constrains that element to allnumerals with a length of exactly five or nine digits. You might want to modify theschema to validate postal codes of other countries. For example, Canada accepts apostal code that has six alphanumeric characters. A document that contains aparagraph would not require any length or type constraint for a paragraph element.
It's clear that narrative documents tend to be looser than database-like documents.They usually don't need the iron discipline possible through an XML schema. Thus,DTDs, not schemas, are often the choice for narrative document grammars.Moreover, people often anonymously exchange these documents, so a standardgrammar is important. A great number of standard DTDs are available. The HTMLDTDs are examples of narrative DTDs. Many DTDs are specialized towardprofessional disciplines.
Surprisingly, an XML schema cannot easily define general entities -- symbolicmacro-like definitions of reusable data. These are usually most useful innarrative-oriented documents. Try to find and incorporate an established DTD andvocabulary for narrative XML documents. To enable fine-grained constraint, considerdefining any rigid database-like vocabulary through an XML schema instead of aDTD.
You can store complex data in an XML document that resides in a flat file. Thismight be satisfactory for small-sized, read-only data. However, when the data islarge or needs to change repeatedly, and if concurrent requests access it, then adatabase management system (DBMS) is probably more appropriate to store thedata. Consider storing XML data in a DBMS if it is subject to massive CRUD orconcurrent requests, or is sizeable.
Next, you need to decide if you want to transform the data into native relationaltables, stuff it into XML binary large objects (BLOBs), or house it in XML stringcolumns. Carefully judge the application's use of the data, remembering that eachXML document requires parsing when it is used. If small subsets of an XMLdocument are often queried or updated, it might be better to store the datarelationally and use SQL access.
DBMS vendors are incorporating more XML support, making XQuery increasinglyattractive. If requests often access an entire XML document in a read-only manner,consider storing the document in a BLOB or in a character column, then use thevendor's XQuery DBMS access.
XML versus non-XML data-exchange methods
Simple Object Access Protocol (SOAP), Really Simple Syndication or Rich SiteSummary (RSS), Electronic Business using eXtensible Markup Language (ebXML),and the Value Object design pattern are examples of data-oriented XML documentsused to carry out data exchange. The data can be arbitrarily complex, and its formatcan be constrained through an involved schema. Using XML for data exchangeallows disparate platforms and languages to create or recognize the data becauseXML is standardized. XML data contains a great deal of statistical redundancy,making it quite compressible for storage or transmission.
The use of XML for data exchange also has downsides. XML is verbose, especiallywhen elements, not attributes, contain metadata. Software processing plays betterwith objects and DOM trees, not angle brackets. Serializing and deserializing (alsocalled creating and parsing, or marshaling and unmarshaling) can be expensive.
You can choose less capable but simpler alternatives to XML data-exchangemodels, especially when you control each end of the exchange. Comma-separatedvalues (CSV) can delimit simple repetitive or position-sensitive data, such asdatabase table rows or spreadsheet data. Name-value pairs can define or transmitoperational properties or nontyped data. JSON is a JavaScript data structure thathas bindings for most other languages.
None of these alternatives is as powerful as XML with an XML schema, but all areworth considering for simplified tasks. As you consider alternatives, remember thatXML promotes portability and understanding across platforms, languages, projects,and data formats. If you use CSV, each party must agree on the meaning of the text
between the commas. A data exchange designer should evaluate XML andalternatives for use in data-exchange design, but remember that XML can conveysemantics, or structure, as well as simply define named pieces of data.
XSLT versus CSS
Cascading Style Sheets (CSS) are used primarily for styling the artistic aspect andcontent positioning within Web pages. The simple syntax is not XML syntax. It issimply a list of XML elements to receive a style. If an element is in a namespace,then its qualified name is used. To attach a CSS stylesheet to an XML document,supply a processing instruction such as the following:
Note that the type is "text/css", not "text/xsl". An optional media attributetargets the stylesheet for only a given media type. CSS transformations are aboutrendering -- making something human-readable to a user.
Contrast CSS to applying an XSLT stylesheet to create an XML document. Thetarget document might be another data description, or it might be visual HTML,depending upon the application. Thus, either CSS or XSLT can create a visualrendering. Which kind of stylesheet is appropriate? Generally, XSLT can transformsemantic data to a viewable form, while CSS is only used for visual effects andplacement of visual objects. Generally, you use XSLT, not CSS, to transform XMLdata into view-layer HTML/XHTML. I recommend CSS transformations only forstyling HTML visual effects and placement, not for transforming the backing data.
Attribute versus element
Developers often wonder if they should design grammars to use attributes orelements. The standard answer is that attributes are metadata -- that is, data aboutdata -- while elements define document structure. In reality, the distinction is not soclear. For example, one could argue that all XML components are metadata.
Clearly, attributes are flat strings with no hierarchy. They have no ordering. If an itemneeds those characteristics, then it should be an element.
Some people claim that everything should be an element. Hierarchies of elementsare usually more human-readable. That was one of the design hallmarks of XML.However, hierarchies of elements take up more space than attributes. If you thinkXML is verbose, picture an HTML dialect having no attributes. At that extreme, a rawdocument could be less human-readable.
Often the choice boils down to aesthetics and style -- unless the item is ordered, hashierarchy, and needs a type constraint, then it has to be an element.
The following sections discuss considerations for optimizing or refining XMLtransformations.
XLST XPath expressions
Recall that XPath is a terse (non-XML) syntax for addressing portions of an XMLdocument. Think about how you would use XPath expressions to accessdocuments. For example the // operator addresses all descendent nodes from thecurrent point. This is more expensive than thoughtfully navigating through children.The same argument applies to the asterisk (*) wildcard used in a query. The goal isto minimize making the processor traverse the entire document repeatedly. ForXPath performance, try not to use expressions that address node aggregates. Forbetter performance, avoid using expressions that might blindly traverse largenumbers of nodes:
<xsl:apply-templates/>
Instead, use elements to match explicit nodes:
<xsl:for-each>
A good approach is to try to use the <xsl:key /> tab and the key() function tocreate name-value pairs for lookups in complex documents.
Client versus server for carrying out transformations
In a multitier application, you must choose where to carry out XSLT transformation toa visual rendition. If you transform on the server, you'll have an easier time beingportable across client browsers. You can tune the operation through intelligentcaching, but otherwise, you might have to plan for scaling concurrent requests.
Instead, you might offload the transformation cycles to the client. This could beattractive for an in-house wide area network (WAN), where a given browser ismandated. Each browser request loads an XML document and an XSLT stylesheet(and probably a CSS stylesheet). If your users are Internet clients, they might have awide variety of browsers. Feature support in newer browsers is converging, but youknow that all of your Internet clients don't have the latest browsers. I recommend
that you evaluate scalability versus portability when you consider offloadingtransformations to client browsers.
Linked stylesheet versus scripted transformation
If you use XSLT transformation to render data to HTML and you decide to carry outthe XSLT transformation on the client side, you still have an additional choice. TheXML data document might have a linked stylesheet. In this case, the browser willattempt to load the stylesheet, carry out the transformation, and render the result.However, the XML document is data. It should not dictate its visual rendition. In fact,it might render differently at different points in the application. For example, onepage might display the entire CD catalog shown in Listing 1, while a subsequentpage might show a selected drill-down to only the Bonnie Tyler CD.
You can separate the view from the data and still carry out the transformationthrough client JavaScript. The JavaScript decides what transformation to carry out,or supplies a transformation parameter that controls it.
The art of browser type-sniffing is important here. Versions of Internet Explorer 6.0and below carry out XSLT through a proprietary ActiveX control, while Mozilla andOpera use a built-in XSLTProcessor object. Internet Explorer 7.0 will support theXSLTProcessor, but you cannot expect the entire public Web community to havethat browser.
On the other hand, if your enterprise WAN mandates a given browser, you cancouple your in-house application design to that browser. Of course, this introduces adependency that you might regret if the organization were to issue a new mandate.These are the kinds of trade-offs you must consider when you design an application.
Example
Let's script an XSLT transformation. You can obtain cdcatalog.xml, shown in Listing1, from W3Schools (see Resources for details).
Next, obtain cdcatalog.xsl, as shown in Listing 2, from W3Schools. This stylesheetgenerates an HTML file table that lists the CD collection in the order it exists in thedocument (you can add a sort to the transformation if you desire).
<h2>My CD Collection</h2><table border="1"><tr bgcolor="#9acd32">
<th align="left">Title</th><th
align="left">Artist</th></tr><xsl:for-each
select="catalog/cd"><tr>
<td><xsl:value-ofselect="title" /></td>
<td><xsl:value-ofselect="artist" /></td>
</tr></xsl:for-each>
</table></body></html>
</xsl:template>
</xsl:stylesheet>
Next create an ajax.js script, shown in Listing 3, in the same work directory as theXML file and the XSL file. This script is browser-independent. The createRequestfunction returns an XMLHttpRequest object used by Mozilla browsers or Operabrowsers to request a file through a URL. Notice that it returns a Microsoft ActiveX®object for Internet Explorer browsers.
Listing 3. ajax.js
function createRequest() {var request = null;try {
Now create the HTML file shown in Listing 4, which consists of JavaScript that getstwo synchronous request objects. It uses one request object to load the XML file,and it uses the other request object to load the XSL file. The objects are notreusable, so you need two.
The script uses an XSLTProcessor object to apply the transformation, thuscreating a DOM node. It inserts this DOM node into an HTML div node, thuscompleting the rendering of the CD catalog. The render function is called duringdocument loading, so the invocation must appear near the document end, after thediv tag, in order to access that tag.
Listing 4. catalog.html
<!DOCTYPE html PUBLIC "-//W3C//DTDXHTML 1.0 Strict//EN""http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"><html><body><script type="text/javascript"src="ajax.js"> </script><script type="text/javascript">
function render(insertionID){var request1 = createRequest();var request2 = createRequest();
// load the xslt filerequest1.open("GET",
"cdcatalog.xsl", false);request1.send(null);
var xslStylesheet =request1.responseXML;var xsltProcessor = new
var fragment =xsltProcessor.transformToFragment(xmlDoc,document);document.getElementById(insertionID).innerHTML= "";document.getElementById(insertionID).appendChild(fragment);}
Figure 1 shows the result in the Firefox browser. This would also work correctly inOpera. However, it won't work in Internet Explorer 6.0 or earlier, due to its missingXSLTProcessor object.
Figure 1. W3Schools example scripted in Firefox
Listing 5 shows catalogIE.html, an Internet-Explorer-centric way of carrying out thetransformation. This page only renders in Internet Explorer, not Firefox or Opera.Melding the two JavaScript-controlled transformations is left as an exercise for theenterprising student. If you use JavaScript to carry out client-side transformations,handle and test browser-dependent issues carefully.
// Load XML into Internet Explorer6.0var xml = newActiveXObject("Microsoft.XMLDOM")xml.async = falsexml.load("cdcatalog.xml")
// Load XSL into Internet Explorer6.0var xsl = newActiveXObject("Microsoft.XMLDOM")xsl.async = falsexsl.load("cdcatalog.xsl")
// Transform within InternetExplorer 6.0document.write(xml.transformNode(xsl))
</script>
</body></html>
Section 4. Testing XML
The phrase testing XML often refers to testing for a well-formed document, testingfor a valid document, testing XSLT transforms, testing XQuery queries, and so forth.The following sections survey the use of free tools or evaluation copies ofcommercial tools to carry out these kinds of tasks. The certification exam does notcover specific tools, but it's important to understand how tools provide the capabilityto create, transform, check, and validate XML files, along with any associated DTDsand schemas.
Firefox DOM Inspector
The free Mozilla Firefox 1.5 Web browser installation package contains a DOMInspector, which you can use to view and edit the DOM of any XML or HTMLdocument. Its installation is an option in the Windows installer package; choose theCustom installation option, then click Developer Tools in the Select componentspopup. To inspect a DOM, browse the desired document. Then, to invoke the DOMInspector, access the Tools > DOM Inspector menu, select Ctrl+Shift+I, or enterfirefox -inspect c:\tmp\locs.xml from the command line.
Figure 2 shows the locs.xml document displayed in DOM Inspector. This tool hasseveral display modes that enable you to display and edit everything contained inthe current browser DOM, including stylesheets and JavaScript. For moreinformation, check out the Firefox DOM Inspector FAQ (see Resources for details).
Your browser is your friend when it comes to go/no-go XML syntax checking orvalidity checking. Simply aim your browser at the local or remote document inquestion. A syntax error resembles the contents of Figure 3. A validity error causesthe browser to display a descriptive message similar to the syntax error example.Use a browser to quickly check for a well-formed document or a valid document.
A correct document renders as a collapsible hierarchy, as shown in Figure 4, unlessit has a linked stylesheet or a JavaScript-controlled transformation that producesHTML. Then, it would resemble Figure 15, near the end of this tutorial, provided thatall goes well.
Carrying out XSLT transformation requests from JavaScript can be frustrating if youhave a simple JavaScript error. The application often quietly fails to operatecorrectly. You know you created an error, but where? The Firefox JavaScriptConsole lists errors, warnings, and messages until you clear it. To invoke JavaScriptConsole, access the Tools > JavaScript Console item.
Each message is a hyperlink to the source that caused it. Figure 5 displays an errormessage in the console that pinpoints where you purposely broke a script used tocarry out the XSLT transformation in the Linked stylesheet versus scriptedtransformation section.
Internet Explorer has a JavaScript (and VBScript) error notification feature that youmust arm to alert you to script errors. From the main menu, click Tools > InternetOptions, then select the Advanced tab. Enable the option Browsing > Display anotification about every script error, as shown in Figure 7.
Figure 7. Enabling Internet Explorer script debugging
Figure 8 shows the kind of popup triggered by a script error. This kind of popupnotification can be handy when errors are few and you don't want to miss them.Otherwise, the Firefox JavaScript Console is more helpful during developmentcycles.
IBM Rational Application Developer, based on the Eclipse IDE, has an XML editorthat features a grid view and a text view. It also includes an XSLT run capability anda debugger that enables you to run a transformation or set breakpoints andsingle-step a transformation, much as you would debug any other program.
To get these features, enable Rational Application Developer for XML. AccessWindow > Preferences to open the Preferences dialog. Choose Workbench >Capabilities, select all XML items, and click Apply or OK. Refer to Figure 9.
To run or debug an XSLT transformation in Rational Application Developer,right-click the XML file in the XML editor in the Package Explorer or the Navigatorview. Choose Run > XSL Transformation to run the transformation and create arun profile for reuse.
To edit this profile, choose the Run menu item next time. You can edit the output fileextension to any file type. See the cdcatalog Run profile in Figure 11.
If you choose xml, the result file will display in the XML Editor, as shown in Figure12. Figure 12 shows Rational Application Developer suspended at a breakpointwhile carrying out the actual transformation in its XSLT debugger. Notice that theRun, Halt, and Step controls appear and operate as they would with a Java programor JavaServer Pages™ (JSP). The Breakpoints view enables you to disable orremove breakpoints as usual.
Figure 12. Debugging XSLT with Rational Application Developer
Altova XMLSpy is a licensed product that features advanced structured editing,validation, and testing functionality for XML documents, DTDs, XML schemas,XSLT, XQuery, Web Services Description Language (WSDL), and other XMLtechnologies.
Even if you cannot justify buying the full product, Altova supplies a freelydownloadable XMLSpy Home Edition that possesses more functionality thanAltova's circa 2001 full product. The installation process creates a Tools > Edit withAltova XMLSpy menu item in the Internet Explorer Web browser. XMLSpy HomeEdition can carry out the following testing and document-authoring tasks:
• Check for well-formed XML
• Validate a document associated with a DTD or schema
• Create a DTD or schema using live assistance hinting
• Display a document outline
• Carry out an XSLT 1.0 transformation
• Render transformation result documents in a browser
• Accept external parameters for an XSLT transformation or an XQuery
The schema locs.xsd, as shown in Listing 6, and a sample associated document,locs.xml, as shown in Listing 7, were created using XMLSpy Home Edition,leveraging its live assistance hints. (I even used it to author this tutorial.)Alternatively, you can use any of a number of XML editors, such as XMLBuddy (seeResources).
Listing 6. locs.xsd
<?xml version="1.0"encoding="UTF-8"?><xs:schemaxmlns="http://rogers60.com/location"xmlns:xs="http://www.w3.org/2001/XMLSchema"targetNamespace="http://rogers60.com/location"elementFormDefault="qualified"attributeFormDefault="unqualified"><!-- Definition of simple
elements --><xs:element name="city"
nillable="false"><xs:annotation><xs:documentation> US
Figure 14 shows the locs.xml document with its associated schema, locs.xsd. Tovalidate the document against the schema, press F8.
Figure 14. XMLSpy with document and schema
Figure 15 shows the cdcatalog.xml and cdcatalog.xsl files from Listing 1 and Listing2. Press F10 to invoke an XSLT transformation that produces the HTML rendering.
XMLSpy Home Edition contains an advanced menu that invites you to try additionalfunctionality for a limited time or to upgrade to the full product. The for-purchasefunctionality includes:
• A more comprehensive schema editor
• An advanced text view
• An XSLT 2.0 debugger
• An enhanced grid view editor
• A SOAP debugger and a WSDL editor
• Database import and export
• Program code generation based on XML content
• Project management source control and WebDAV support
Parts 1 through 4 of this series discussed applied aspects of XML and its commonrelated technologies (Resources). This tutorial completed the series by explaininghow to choose the appropriate XML technologies for the problem at hand. It showedyou how to optimize transformations, refine designs, and understand how simplechoices affect performance. It demonstrated simple examples of how to usecommon tools to test XML designs, then went on to describe how to test XML usingcommonly available tools.
If you study the complete series, you should have sufficient background to help youprepare to take the IBM certification Test 142, XML and Related Technologies, toattain the IBM Certified Solution Developer - XML and Related Technologiescertification.
• XML on developerWorks: Get the resources you need to advance your XMLskills with technical articles and tips, tutorials, standards, and IBM Redbooks.
• New to XML page (developerWorks): Browse this overview if you want to learnabout XML but don't know where to start.
• IBM XML 1.1 certification: Become an IBM Certified Developer in XML 1.1 andrelated technologies.
• Introduction to XML tutorial (Doug Tidwell, developerWorks, August 2002):Learn what XML is, why it was developed, and how it's shaping the future ofelectronic commerce. It also covers a variety of important XML programminginterfaces and standards.
• XML in a Nutshell, 3rd Edition (Elliotte Rusty Harold and W. Scott Means,O'Reilly Media, 2004, ISBN: 0596007647): Check out this comprehensive XMLreference with everything from fundamental syntax rules, DTD and XMLSchema creation, XSLT transformations, processing APIs, XML 1.1, plus SAX2and DOM Level 3.
• XML Schema Part 0: Primer Second Edition on the W3C Web site: Read aboutthe XML Schema and how to create schemas using the XML Schemalanguage.
• W3C Markup Validation Service: With this free service, check Web documentsin formats like HTML and XHTML for conformance to W3C Recommendationsand other standards.
• Apache Xerces: Read about this popular Java-based DOM and SAX parser.
• XHTML: Learn more about XHTML on the Wikipedia Web site.
• W3Schools XML Tutorial: Learn what XML is, the difference between XML andHTML, and how to use XML in your applications.
• W3Schools DTD Tutorial: Check out the purpose of a DTD (Document TypeDefinition) and how to use it.
• W3Schools XML Schema Tutorial: Learn to read and create XML Schemas,why XML Schemas are more powerful than DTDs, and how to use the XMLSchema language in your applications.
• Firefox DOM Inspector FAQ: Find answers to questions about this tool thatviews and edits the DOM of XML and HTML documents.
• developerWorks technical events and webcasts: Stay current with technology inthese sessions.
Get products and technologies
• IBM product evaluation versions: Download and try application development
• Mozilla Firefox Web browser: Download Firefox 1.5 with its support of openWeb standards for free.
• Eclipse SDK: Download the Eclipse SDK, then browse the various projectpages to find the useful tools and plugins that you need.
• Altova XMLSpy 2006 Home Edition: Download a free entry-level XML editor anddevelopment tool for designing and editing XML-based applications.
• FireBug: Download this Firefox browser DOM and script extension.
• XMLBuddy: Download an XML editor plug-in for the Eclipse IDE.
• Microsoft Internet Explorer 6.0 or its successors: Download this browser that'sbundled with Microsoft Windows and Mac OS/X operating systems.
• cdcatalog.xml: Download this sample XML file from W3Schools.
• cdcatalog.xsl: Download this sample XSL file from W3Schools.
Discuss
• XML zone discussion forums: Participate in any of several XML-centeredforums.
• developerWorks blogs: Get involved in the developerWorks community.
About the author
Louis E MaugetLou Mauget is a senior Java™ 2 Enterprise Edition (Java EE) consultant andpublished author who lives near Raleigh, North Carolina. He consults to variousenterprise and government clients. Lou was a software engineer for IBM before hiscurrent position with Number Six Software. He continues to participate in certificationactivity for IBM. You can reach Lou at [email protected].
Trademarks
IBM, DB2, Lotus, Rational, Tivoli, and WebSphere are trademarks of IBMCorporation in the United States, other countries, or both.Java and all Java-based trademarks are trademarks of Sun Microsystems, Inc. in theUnited States, other countries, or both.Linux is a trademark of Linus Torvalds in the United States, other countries, or both.
