Web services have become a fixation for many developers because they view the Internet as the best way to promote application communication. Some Web services, such as Amazon.com Web Services, are public and easily accessible to any developer who needs to include that service in an application. Other Web services are private and require special knowledge for access. No matter what type of Web service is involved, they all rely on XML to transmit data. Consequently, this is the first thing developers think about when you mention XML parsing.
Other Uses for XML Parsing
XML parsing covers more than just Web services. For example, .NET applications can use XML as a means of configuration. All you need is a .MANIFEST file with the same name as the application, and the Common Language Runtime (CLR) automatically looks into the file for configuration information.
For example, Listing 1 shows an XML addition to a .MANIFEST file. This manifest tells CLR to use the Windows XP theme information to draw the standard controls (the configuration file doesn't affect owner-drawn controls). Note that the version number of this file could change and you should look for the current version number in the \WINDOWS\WinSxS folder of your system. The folder for the side-by-side library has a name such as x86_Microsoft.Windows.Common-Controls_6595b64144ccf1df_188.8.131.52_x-ww_1382d70a, where the processorArchitecture value shown in Listing 1 appears first, the name value appears second, the publicKeyToken value appears third, and the version value appears fourth.
Listing 1 .NET .MANIFEST Files Rely on XML
<?xml version="1.0" encoding="UTF-8" standalone="yes"?> <assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0"> <assemblyIdentity type="win32" name="ShowMessage" version="184.108.40.206" processorArchitecture="x86" /> <dependency> <dependentAssembly> <assemblyIdentity type="win32" name="Microsoft.Windows.Common-Controls" version="220.127.116.11" processorArchitecture="X86" publicKeyToken="6595b64144ccf1df" language="*" /> </dependentAssembly> </dependency> </assembly>
You can also create other configuration files that your application parses as part of the startup process. These files can contain any information the application needs to execute. You can use these configuration files in place of registry settings. In general, you'll find that there are fewer errors using XML files than using the registry, and they're also more flexible. For example, moving a user from one machine to another need not entail reconfiguring the application because the settings already appear in the same folder as the application. In some respects, this means that we're almost moving back to using INI files, but XML files contain a great deal more information than INI files do and are less likely to experience certain forms of damage and configuration errors.
When combined with other technologies, such as eXtensible Stylesheet Language Transformations (XSLT), XML can also make Web pages easier to read. However, you can also use such techniques for internal use. For example, many companies are turning to this form of XML as a means to create help files for users. The help information appears as data in XML files that a browser transforms into viewable output using an XSLT file. The application displays the information using an HTML-compatible control. As far as the user is concerned, the data comes from a standard help file or another information source.
Eventually, XML could become a major data storage technique. Some vendors already discuss their XML offerings. You can also find XML storage in products such as Microsoft Office. In short, you might eventually find that you need parsing capability in your application to even load the data and present it onscreen.