So now you’ve managed to sort through the alphabet soup of XML-related technologies. You even have realized that there may be more to XML than just another way to build a presentation layer. But you aren’t quite sure where XML fits in with the applications you are building at work. You aren’t positive that you could convince your boss to let you spend time learning more about XML, because you don’t know how it could help make a better application. You even are thinking about trying to evaluate some tools to use XML, but you aren’t sure where to start.
If this is the situation you find yourself in, excited about a new technology but confused as to where to go next, then read on! In this section, we begin to cast XML in the light of real-world applications, and give you a reason to use XML in your applications today. We will first look at how XML is being used today in applications, and we’ll give you the information to convince that boss of yours that “everybody’s doing it.” Next we will take a look at support for XML and related technologies, all in light of Java applications. In Java, there is a wealth of available parsers, transformers, publishing engines, and frameworks designed specifically for XML. Finally, we will spend some time looking at where XML is going and try to anticipate how it will affect applications six months and a year from now. This is the information to use to convince your boss’s boss that XML can not only keep you even with your competitors, but give your company the leading edge in your industry, and help get you that next promotion!
Even if you have been convinced that XML is a great technology, and that it is taking the world by storm, we have yet to mention why this book is about Java and XML, rather than just XML alone. Java is, in fact, the ideal counterpart for XML, and the reason can be summed up in a single phrase: Java is portable code, and XML is portable data. Taken separately, both technologies are wonderful, but have limitations. Java requires the developer to dream up formats for network data and formats for presentation, and to use technologies like JavaServer Pages™ (JSP) that do not provide a real separation of content and presentation layers. XML is simply metadata, and without programs like parsers and XSL processors, is essentially “vapor-ware.” However, Java and XML matched together fill in the gaps in the application development picture.
Writing Java code assures that any operating system and hardware with a Java™ Virtual Machine ( JVM) can run your compiled bytecode. Add to this the ability to represent input and output to your applications with a system-independent, standards-based data layer, and your data is now portable. Your application is completely portable, and can communicate with any other application using the same (widely accepted) standards. If this isn’t enough, we’ve already mentioned that Java provides the most robust set of APIs, parsers, processors, publishing frameworks, and tools for XML use of any programming language. With this synergy in mind, let’s look at how these two technologies fit together, both today and tomorrow.
Many developers and technology-driven companies are under the impression that while XML is certainly a hot topic, and has reached “buzzword” status, it is not yet ready for the mission-critical applications that companies rely on so heavily. Nothing could be further from the truth. XML and the related technologies we have been discussing have gained a firmer place in the application space in a shorter amount of time than even Java was able to achieve when it was announced several years ago. In fact, XML is possibly the only announcement in the development world to rival the impact of the Java platform. It is fortunate for us as developers that these are complementary technologies rather than competing ones. With Java and XML, portability of applications and data is at an all-time high, and is being used heavily, right now, as you read this chapter.
The most popular use for XML is to
create a separation of content and presentation. In this situation,
we are defining application
content
as the data that needs to be displayed
to a client, and application presentation as the formatting of that data.
For example, a user’s name and address in an administrative
section of an ordering system would be content, while the
HTML-formatted page with images and company branding would be the
presentation. The primary distinction is that content is universal
for an application, and no matter what type of client-specific
formatting must occur, the same content is valid; however,
presentation is specific to the type of client (web browser,
Internet-ready phone, Java application) and that client’s
capabilities (HTML 4.0, the Wireless Markup Language, Java™
Swing) to view data. XML is being used to represent the content in
this situation, while XSL and XSLT are used to provide a presentation
suitable for the client.
One of the most significant challenges that applications face today, particularly web applications, is the variety of clients that might need to use the application. Ten years ago, users were almost always thick clients with software installed on their desktop computer to use an application; three years ago, application clients were almost always Internet web browsers that understood HTML. Clients today use web browsers on a multitude of operating system platforms, wireless mobile phones with Wireless Markup Language (WML) support, and handheld organizers that support a subset of HTML. This variety of client types often results in an application having numerous versions, one for each type of client it supports, and still not supporting all client variations. Although an application may not need to support a wireless phone, certainly there are advantages to allowing employees or customers the service if they have the equipment; and while a handheld organizer may not allow a user to perform all the operations that a web browser might, frequent travelers who could manage their accounts online would certainly be more likely to continue to use a service that a company provides. The shift from lots of functionality being offered to specific types of clients to a standard set of functionality being offered to an enormous variety of client types has left many companies and application developers scratching their heads. XML can resolve this confusion.
Although we said earlier that XML is not a presentation technology, it can be used to generate a presentation layer. If there doesn’t seem to be much of a difference between the two, consider this: HTML is a presentation technology. It is a markup language designed specifically to allow graphical views of content for web browser clients. However, HTML is not by any means a good data representation. An HTML document is not easy to parse, search, or manipulate. It follows only a loose format, and is at least one-half presentation information, if not more, while only a small percentage of the document is actual data. XML is substantially different, as it is a data-driven markup language. Nearly all of an XML document is data and data structure. Only instructions to an XML parser or wrapping application are not data-centric. XML is easily searchable and can be manipulated with APIs and tools due to the strict structure a DTD or schema can impose. This makes it very non-presentation-oriented. However, it can be used for presentation with its companion technologies, XSL and XSLT. XSL allows definition of presentation and formatting constructs and instructions on how to apply these constructs to the data within an XML document. And through XSLT, the original XML can be displayed to a client in a variety of ways, including very complex HTML. Still, the core XML document remains separate from any presentation-specific information and can just as easily be transformed into an entirely different style of presentation, such as a Swing user interface, with no change to the underlying content.
Perhaps the most powerful component offered by XML and XSL for presentation is the ability to specify multiple stylesheets to an XML document, or to impose XSL stylesheets on an XML document externally. This adds another layer of flexibility to presentation, as not only can the same XML document be used for multiple presentations, but the publishing framework performing transformation can determine what type of client is requesting the XML document and select the correct stylesheet to apply based on that information. While there is no standard way of performing this process, and no standard set of codes for various client types, an XML publishing framework can provide ways to accomplish this dynamic transformation. The process of specifying multiple XSL stylesheets within an XML document is not vendor-specific, so the only framework details your XML document should have to worry about may be an additional processing instruction or two. Because these are simply ignored if not supported by an application, the XML documents used remain completely portable and 100% standard XML.
In addition to these useful transformation capabilities, the same XML document and its data content can be used to transfer information between applications. This communication is easily achievable because the XML data is not tied to any type of client, or even to being used by a client. It also provides a very simple data representation easily transmissible over a network. It is this communication aspect of XML that is probably the most overlooked and undervalued feature of XML documents and data representations.
To understand the importance of XML for communications, you must first widen your concept of an application client. While talking about presentation, we made the common assumption that a client is a user that views a portion of an application. However, this is a fairly narrow assumption in today’s applications, and we will now discard it. Instead, consider that a client is anything (yes, anything!) that accesses data or services within an application. Clients can be users with computers or mobile devices, other applications, data storage systems like databases or directory services, and even, at times, the application itself making callbacks. When the view of a client is widened like this, you will begin to see the impact that XML can have.
First, categorize these client types into two groups: one that requires a presentation layer and one that doesn’t. When you begin to do this, you may find it a little difficult to draw such a distinction. While users certainly might view data as HTML or WML (Wireless Markup Language), data might need to be formatted a little differently for another application, possibly filtering out some secure content or using different element names. In fact, there will rarely be a time when a client does not need data formatted in a manner somewhat specific to the purpose the data is being used for.
This exercise should convince you that data is almost always transformed, often multiple times. Consider an XML document that is converted to a format usable for another application by an XSL stylesheet (see Figure 1.2). The result remains XML. That application may then use the data to gain a new result set, and create a new XML document. The original application then needs this information, so the new XML document is transformed back into the format used by the original application, although it now contains different data! This scenario is a very common one.
This repeated process of transforming a document, and always generating a new XML result, is what makes XML such a powerful tool for communication. The same set of rules can be used at every step, always starting with XML, applying one or more XSL stylesheets over one or more transformations, and resulting in XML that is still usable with the same tools that initially created the original document.
Also consider that XML is a purely textual representation of data. Because text is such a lightweight and easily serialized data representation, XML provides a fast means of transmitting data across a network. Although some binary data formats can be transmitted very efficiently, textual network transmissions will typically average out as a faster means of communication.
One specification concerned with using XML for communication is XML-RPC. XML-RPC is concerned with communication not between applications, but between components within an application, or to a shared set of services functioning across applications. RPC stands for Remote Procedure Calls, one of the primary predecessors of Remote Method Invocation (RMI). RPC is used for making procedural calls over a network, and receiving a response, also over the network. Note that this is significantly different than RMI, which actually allows a client to invoke methods on an object via stubs and skeletons loaded over the network. The primary difference is that RPC calls generate a remote response, and the response is returned over the network; the client never interacts directly with a remote object, but instead uses the RPC interfaces to request a method invocation. RMI allows a client to directly interact with a remote object, and no “proxying” of requests takes place. For a more complete discussion on exactly what XML-RPC is, you should visit http://www.xml-rpc.com.
The point worth noting about RPC, and XML-RPC in particular, is that it has now become a viable option for remote service calls. Because of the difficulty of providing a standard request and response model, RPC has become almost extinct in Java applications, and has been replaced by RMI. However, there are often times when rather than loading remote stubs and skeletons over a network, sending and receiving textual data results in higher performance. The historical problem of RPC has been trying to represent complex objects with nothing but textual information, both for requests and responses. XML has solved this problem, and RPC is again a possible solution for allowing disparate systems to communicate. With a standard in place for representing any type of data through textual documents, an XML-RPC engine can map an object instance’s parameters to XML elements, and can easily decode this “graph” of the object on the server. A response can be generated, and again, can easily be “graphed” into XML and returned to the client (see Figure 1.3). We will look at XML-RPC in detail in Chapter 10.
The last use of XML for communication is really not a different use or specification than those we have already talked about; however, the rise of the phrase "business-to-business” commerce and communication bears mentioning. Business-to business-communication generally refers to communication not just between differing applications, but across companies and sometimes industries. In these cases, XML is truly performing a significant service only available to extremely large companies in the past; it is allowing communication between closed systems. Consider a small- to medium-sized competitive local exchange carrier (CLEC), or a telecommunications company. When a network line, such as a DSL or T1, is sold to a customer, a variety of things must happen (see Figure 1.4). The provider of the line, such as UUNet, must be informed of the request for a new line. A router must be configured by the CLEC and the setup of the router must be coordinated with the Internet service provider. Then an installation must occur, which may involve another company if this process is outsourced. This relatively common and simple sale of a network line already involves three companies! Add to this the technical service group for the manufacturer of the router, the phone company for the customer’s other communication services, and the Internic to register a domain, and the process becomes significant.
This rather intimidating process can be made extremely simple with the use of XML (as shown in Figure 1.5). Imagine that the initial request for a line is input into a system that converts the request into an XML document. This document is then transformed, via XSL, into a format that can be sent to the line provider, UUNet in our example. UUNet then adds line-specific information, transforming the request into yet another XML document, which is returned to the CLEC. This new document is passed on to the installation company with additional information about where the client is located. Upon installation, notes detailing whether or not the installation was successful are added to the document, which is transformed again via XSL, and passed back to the original CLEC application. The beauty of this solution is that instead of multiple systems, each using vendor-specific formatting, the same set of XML APIs can be used at every step, allowing a standard interface for the XML data across applications, systems, and even businesses.
One last significant use of XML in applications and Java technologies today is at the application server level. The Enterprise JavaBeans (EJB) 1.1 specification requires that deployment descriptors for Enterprise JavaBeans, which define the behavior and other information about EJBs, be XML based. This is a replacement for the previously used serialized deployment descriptors. In the EJB realm, this is a welcome change, as it removes vendor specificity from deployment descriptors. By requiring deployment descriptors to conform to a predefined DTD, vendors can all use the same XML deployment descriptors, increasing EJB portability.
XML is also used for configuration of the servlet API, version 2.2. An XML file, which specifies the connector parameters to use, the servlet contexts to start up, and other engine-specific details, configures the servlet engine itself. XML configuration files are also used to configure individual servlets, allowing initial arguments, servlet aliasing, and URL matching to be accomplished for specific servlet contexts.
Although both the EJB 1.1 specification and the Tomcat servlet engine are fairly new to the Java world, their inclusion of XML as core to their configuration is indicative of Sun’s intention to continue to use XML for these purposes. As XML parsers become increasingly common and marketable, XML-based configuration files are expected to increase across all server vendors and types, including non-Java-based servers, such as HTTP and database servers.
In the middle to late months of 1999, support for XML has blossomed, particularly for the Java platform. XML parsers, XSLT processors, publishing frameworks, XML editors and IDEs, and a wealth of related tools have become available and are even now becoming stable and extremely fast. Although the subject of this book is the Java APIs for directly manipulating XML, the parsers, processors, and other components are certainly a part of the overall process of using XML, so a reference on available components is included. Because the XML technology is changing so rapidly, and companies are devoting more time and energy to the platform than ever before, no versions are listed here; they would almost certainly be long out of date by the time this book gets into your hands. In addition, it is possible, even likely, that many more tools will be available than are listed here by the time you read this. You should consult your vendors to see if they have XML support or tools if you do not see them listed here.
One of the most important layers to an XML-aware application is the XML parser. This component handles the extremely important task of taking a raw XML document as input and making sense of the document; it will ensure that the document is well-formed, and if a DTD or schema is referenced, it may be able to ensure that the document is valid. What results from an XML document being parsed is typically a data structure, in our case a Java-based one, that can easily be manipulated and handled by other XML tools or Java APIs. We will not detail these data structures now, as they are discussed in great depth in later chapters. For now, just realize that the parser is one of the core building blocks to using XML data.
Selecting an XML parser is not an easy task. There are no hard and fast rules, but two main criteria are typically used. The first is the speed of the parser. As XML documents are used more often and their complexity grows, the speed of an XML parser becomes extremely important to the overall performance of an application. The second factor is conformity to the XML specification. Because performance is often more of a priority than some of the obscure features in XML, some parsers may not conform to finer points of the XML specification in order to squeeze out additional speed. You must decide on the proper balance between the two factors based on your application’s needs. In addition, some XML parsers are validating, which means they offer the option to validate your XML with a DTD, and some are not. Make sure you use a validating parser if that capability is needed in your applications.
Here’s a list of the most commonly used XML parsers. The list does not show whether a parser is validating or not, as there are current efforts to add validation to several of the parsers that do not yet offer it. No overall ranking is given or suggested here, but there is a wealth of information on the web pages for each parser:
Apache Xerces: http://xml.apache.org
IBM XML4J: http://alphaworks.ibm.com/tech/xml4j
James Clark’s XP: http://www.jclark.com/xml/xp
OpenXML: http://www.openxml.org
Oracle XML Parser: http://technet.oracle.com/tech/xml
Sun Microsystems Project X: http://java.sun.com/products/xml
Tim Bray’s Lark and Larval: http://www.textuality.com/Lark
The W3C has stated that they intend to release an open source schema validating parser.
Warning
The Microsoft parser has been intentionally left out of this list; from all appearances, Microsoft does not now or in the future intend to conform to W3C standards. Instead, Microsoft seems to be developing their own flavor of XML. We have seen this before . . . be careful if you are forced to use Microsoft’s parser, MSXML.
After an XML document is parsed, it is almost always transformed. This transformation, as we have discussed, is accomplished through XSLT. Similar to parsing, there are a wide variety of options for this component of the XML process. Again, the two primary considerations are speed of transformation and conformity to XSL and XSLT specifications. At the time of this writing, XSL has just become a full W3C Recommendation, so the level of support for all XSL constructs and options is in great flux. The web site for each processor is the most informative location for determining conformance and for searching for performance benchmarks.
Apache Xalan: http://xml.apache.org
James Clark’s XT: http://www.jclark.com/xml/xt
Lotus XSL Processor: http://www.alphaworks.ibm.com/tech/LotusXSL
Oracle XSL Processor: http://technet.oracle.com/tech/xml
Keith Visco’s XSL:P: http://www.clc-marketing.com/xslp
Michael Kay’s SAXON: http://users.iclway.co.uk/mhkay/saxon
An XML publishing
framework
is a bit of a nebulous term, and
certainly is not a formal definition. For the purposes of this book,
a publishing framework for XML is considered to be a suite or set of
XML tools that allow parsing,
transformations, and possibly additional options for using XML within
applications. Although the parsing and transforming is generally
accomplished by using some of the tools we have already mentioned, a
publishing framework ties these tools together with Java APIs, and
provides a standard interface for using the framework. More advanced
frameworks allow for processing of both static XML documents and XML
generated by Java applications, and some offer editors and component
builders to ensure that generated XML fits the framework’s
constraints.
Because there is no specification for how an XML application or framework should behave, there is a tremendous amount of variety between the frameworks listed here. However, each has benefits that are significant enough to merit you spending some time looking at and using them. Additionally, several of these frameworks are open source software (OSS), and thus are not only accessible, but also open in that you can see exactly how things were accomplished. When we begin building application components later we will select a framework that best suits the examples, but for now, that decision is deferred so that you can do your own research based on your application’s needs.
Apache Cocoon: http://xml.apache.org
Enhydra Application Server: http://www.enhydra.org
Bluestone XML Server: http://www.bluestone.com/xml
Although there are many strong XML parsers and processors available, the same cannot be said for XML editors. Unfortunately, XML is in a similar situation to that of HTML several years ago; embraced by a small, highly technical group of developers, XML is most often created in text editors like vi, emacs, and notepad. Although there have been some recent offerings in the XML editor space, these offerings have been slow to mature, and are only now becoming usable. IBM does seem to be making significant strides towards providing editing tools for XML, and their latest offerings can be seen at http://alphaworks.ibm.com/. In addition, http://www.xmlsoftware.com provides an excellent, current listing of XML products, and should be consulted for the latest software offerings.
To complete our look at how XML is being used, it seems only fair to try to anticipate where XML will be used tomorrow. XML is often referred to as the technology of the future. In fact, many companies and developers have held off using XML because they claim that it is not quite mature enough, but all admit that it will change the way applications are built in the next year. While the issue of XML’s maturity is arguable, as evidenced by the many excellent uses for XML we have already discussed, the claim that it will revolutionize application development is not. Even those who do not use it heavily today are aware that they will have to use it eventually, and “eventually” gets closer every day.
Despite all the hype surrounding XML, and its massive promise, trying to anticipate where XML will be a year from now, or even six months from now, is almost impossible. It is a bit like trying to guess where a quirky OO language called Java that was great for building applets would go about four years ago: in other words, there is no telling! However, there are several trends in the use of XML that can help us anticipate what we may soon see on the horizon. Next, we take a look at some of the most significant of those ideas.
We have already discussed how XML is increasingly being used for server configuration. Because XML provides such an easy representation of data, it is ideal for configuration files; these files have historically been cryptic, difficult to use and modify, and very vendor-specific. For example, look at a portion of the configuration file for an Apache HTTP server, shown in Example 1.5.
Example 1-5. Apache HTTP Server Configuration File
ServerType standalone ServerRoot "e:/java/server/apache/http" PidFile logs/httpd.pid ScoreBoardFile logs/apache_status Timeout 300 KeepAlive On MaxKeepAliveRequests 100 KeepAliveTimeout 15 MaxRequestsPerChild 0 ThreadsPerChild 50 Listen 80 Listen 85
While this is fairly straightforward, it is radically different from the configuration file for a Weblogic server, shown in Example 1.6.
Example 1-6. Weblogic Server Configuration File
weblogic.security.ssl.enable=true weblogic.system.SSLListenPort=7002 weblogic.httpd.register.authenticated= weblogic.t3.srvr.ClientAuthenticationServlet weblogic.security.certificateCacheSize=3 weblogic.httpd.register.T3AdminCaptureRootCA=admin.T3AdminCaptureRootCA weblogic.security.clientRootCA=SecureServerCA.pem weblogic.security.certificate.server=democert.pem weblogic.security.key.server=demokey.pem weblogic.security.certificate.authority=ca.pem weblogic.httpd.register.Certificate=utils.certificate weblogic.allow.execute.weblogic.servlet.Certificate=system weblogic.httpd.enable=false
These two configuration files use entirely different syntax. Although different services will usually define their own DTDs and element names, XML allows formalization and standardization of file formatting, producing a universal configuration language. This can only help system and network administrators, as well as developers, over time.
You may be thinking that we have already covered configurations; why are we going through this again? Currently, each server has a local configuration file (or files). Although some servers are moving to using directory services for configuration, this has been slow in adoption, and requires knowledge of the directory service protocol, typically the Lightweight Directory Access Protocol (LDAP). A growing trend is the concept of creating an XML repository for configuration (see Figure 1.6). There is also growing support for a Java Naming and Directory Interface™ ( JNDI) provider for XML, similar to a file provider. In this situation, XML could either function separately from a directory service or as an abstraction layer over a directory service, allowing applications to need only an XML parser to obtain configuration information. This is substantially easier and more powerful than providing LDAP libraries with servers. In addition, as more servers become XML aware, the ability to store configurations in a central location allows interoperability between components. HTTP servers can discover what servlet engines are available and self-configure connectors. Enterprise JavaBean containers can locate directory services on the network and register beans with those directories, as well as discover databases that can be used for object persistence. These are just a few of the options available when standalone servers are discarded for networked servers, all using a common XML repository for configuration information .
XSP stands for Extensible Server Pages, and is yet another XML-related acronym that has the potential to throw the Java community into excited action. XSP is currently a working draft authored by Ricardo Rocha and Stefano Mazzocchi, the lead developers on the Apache Cocoon project. Although not adopted by the W3C or any other formal organization at the time of this writing, it is possible that the XSP draft may make its way to one of those committees by the time you are reading this chapter. In a nutshell, XSP seeks to provide the frontend portion of an XML framework, providing dynamic XML pages that are parsed and transformed by the framework and allow application interoperability, yet are constructed and stored as static files on a filesystem.
To those of you familiar with Java server-side components, you probably realize that this sounds a lot like JSP, or at least an XML version of JSP. To some degree, you are right. XSP offers an XML, and therefore language-independent, alternative to a scripting language for building web pages and web sites. Much as enterprise applications in Java are aimed at providing a clear separation of content from application and business logic, XSP seeks to provide the same for XML-based applications. Although many of the currently available XML frameworks allow this separation of layers within compiled code, changes to the formatting of actual data in an XML document still require changes to Java code and a subsequent recompilation. This is in addition to any changes that might result from changing the actual presentation and related XSL stylesheet. In addition, XSP defines a process of allowing XSLT transformations to take place within the document, but allows programmatic transformations as well as presentation ones. For example, consider the sample XSP document (based on an example from the XSP working draft) shown in Example 1.7.
Example 1-7. A Simple XSP Page
<?xml version="1.0"?> <xsp:page language="java" xmlns:xsp="http://www.apache.org/1999/XSP/Core" > <title>A Simple XSL Page</title> <p>Hi, I've been hit <counter/> times.</p> </xsp:page>
In addition to being well-formed and easily validated XML, there is
no programming logic within the XSP page. This is where XSP diverges
from JSP; logic, and therefore coding structures, are defined in an
associated logicsheet (analogous to an XSL stylesheet) rather than
within the XSP page itself. This allows complete language
independence within XSP, and the abstraction of language-specific
constructs in the logicsheet. The following logicsheet in Example 1.8 would handle the transformation of the
<counter/> tag and the rest of the XSP page
into actual content.
Example 1-8. XSP Logicsheet
<?xml version="1.0"?>
<xsl:transform
xmlns:xsl="http://www.w3.org/1999/XSL/Tranform"
xmlns:xsp="http://www.apache.org/1999/XSP/Core"
>
<xsl:template match="xsp:page">
<xsp:page language="java">
<xsp:structure>
<xsp:include>java.lang.*</xsp:include>
</xsp:structure>
<xsp:logic>
private static int counter = 0;
private synchronized int currentCount( ) {
return ++counter;
}
</xsp:logic>
<xsp:content>
<page>
<xsl:apply-templates/>
</page>
</xsp:content>
</xsp:page>
</xsl:template>
<xsl:template match="counter">
<xsp:expr>currentCount( )</xsp:expr>
</xsl:template>
<!-- Transcribe everything else verbatim -->
<xsl:template match="*|@*|comment( )|pi( )|text( )">
<xsl:copy>
<xsl:apply-templates/>
</xsl:copy>
</xsl:template>
</xsl:transform>You should be able to understand what is happening here with very
little explanation. Although XSP does offer some new constructs, such
as <xsp:structure> and
<xsp:logic>, the remainder of the document
looks like a standard XSL stylesheet. The XSP tags are also very
clear and understandable, allowing inline coding of Java in this
example.
Although XSP is currently available only as part of the Apache Cocoon project, it is an extremely well thought out draft, and will very likely provide XML-aware applications with the ability to remain abstracted from presentation details much more efficiently than possible today. It also offers an easier entry path into XML, much as JSP has encouraged many developers not familiar with Java to learn JSP and then move on to more complex Java APIs. XSP may further the spread of XML in addition to offering the advantages we’ve already discussed. For more information on XSP and to view the complete Layer 1 Working Draft, visit http://xml.apache.org/cocoon/xsp.html on the Web.
Get Java and XML now with the O’Reilly learning platform.
O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.
