The Extensible Markup Language (XML) has been anointed as the universal duct tape for all software integration problems despite XML's relatively humble origins in the world of document management systems. Essential XML presents a software engineering-focused view of XML and investigates how XML can be used as a component integration technology much like COM or CORBA. Written for software developers and technical managers, this book demonstrates how XML can be used as the glue between independently developed software components (or in the marketecture terminology du jour, how XML can act as the backplane for B2B e-commerce applications).
Authors Don Box, Aaron Skonnard, and John Lam cover the key issues, technologies, and techniques involved in using XML as the adhesive between disparate software components and environments. They explain the fundamental abstractions and concepts that permeate all XML technologies, primarily those documented in the XML Information Set (Infoset). XML-based approaches to metadata, declarative, and procedural programming through transformation and programmatic interfaces are covered. Don Box, co-author of the Simple Object Access Protocol (SOAP) specification, provides readers with insight into this emerging XML messaging technology for bridging COM, CORBA, EJB, and the Web.
Readers acquire a better understanding of XML's inner workings and come to see how its platform, language, and vendor independence--along with its accessibility--make it an extraordinarily effective solution for software interoperation.
1. Beyond Markup.
Types and XML.
Where Are We?
Simple API for XML Version 2 (SAX2).
Auxiliary SAX Interfaces.
SAX and I/O.
SAX Error Handling.
The Glue of SAX: XMLReader.
The Document Object Model.
The Object Model.
The DOM and Factories.
The Node Interface.
Parents and Children.
Element and Attribute Nodes.
Document, Document Type, and Entity Nodes.
Bulk Insertion Using Document Fragment.
DOM Error Handling.
Implementation vs Interface.
Where Are We?
Navigation and URLs.
URL + Xpath == Xpointer.
Ranges and Points.
Where Are We?
Content Models and Particles.
Reference and Uniqueness Constraints.
Where Are We?
Namespaces and XSLT.
Where Are We?
Where Are We?
XML as a Better Component Model.
Documents as Messages.
Where Are We Going?
W3C Working Draft 20 December-1999.
Status of this Document.
2. Information Items.
5. What is not in the Information Set.
Appendix A: XML 1.0 Reporting Requirements (informative).
Appendix B: RDF Schema (informative).
Sorted by production number.
Sorted by name.
XML Schema Examples.
XML has replaced Java, Design Patterns, and Object Technology as the software industry's solution to world hunger. The trade press has anointed XML as the universal duct tape for all software integration problems, and the large vendors happily support this vision by integrating XML into everything including database engines, development tools, web browsers, and operating systems. This is especially ironic given the relatively humble origins of XML, which lie squarely in the world of document management systems. Despite these somewhat unglamorous origins, the industry at large is out to recast all things good and honorable in terms of XML whether it makes sense or not. Rather than simply stand on the sidelines questioning the relative nakedness of the emperor du jour, we have written this book largely as an exercise to sort out for ourselves what XML really means to the software practitioner. As Addison-Wesley (and DevelopMentor) were both kind enough to fund our work, the least we can do is let them publish the travelogue to recoup their investment. DevelopMentor has also been kind enough to donate web space for the support page for this book. That page can be found at http://www.develop.com/books/essentialxml.
The XML community is a community divided. On one side is the "document" camp; on the other side is the "data" camp. The document-centric view of XML purports that an XML document is an annotated text file that contains markup directives to control the formatting and presentation of the contained text. The data-centric view advocates that XML is but one of many representations of a typed value that software agents can use for data interchange and interoperation. The document-centric view assumes that tools like emacs, notepad, or high-priced document management systems will generate XML. This viewpoint emphasizes the syntax of XML and treats the angle bracket as the central theme of XML. The data-centric view assumes that XML is yet another serialization format that will never be manipulated or viewed directly by humans. This viewpoint relegates the syntax of XML to a minor detail that is only important to the small handful of people who write low-level XML parsers. This book falls squarely in this latter camp. That stance may offend some readers; however, it is the authors' strong belief that the ratio of hand-authored XML to software-generated XML is in sharp decline.
XML is a family of layered technologies. This book uses the layering model of XML as its guide and looks at each technology as it relates to the core XML specification: the XML Information Set (Infoset). The Infoset is the most pivotal of all XML specifications, as it describes exactly what an XML document is in syntax-free terms. Most interesting XML specifications and technologies are written in terms of the Infoset. This makes many XML technologies generalizable to applications that do not use the XML 1.0 serialization format, which has extremely interesting implications for the future of XML. The book is organized as follows:
XML is simultaneously an abstract data model and a serialization format. This chapter looks at the relationship between these two roles and presents a detailed overview of the structural model of an XML document as it is described in the XML Information Set (Infoset) specification.
At the time of this writing, there were two common projections of the Infoset onto programmatic types. The Simple API for XML Version 2 (SAX2) and the Document Object Model Level 2 (DOML2) present completely different models over the same underlying Infoset. This chapter looks at the similarities and differences between the two models. The Apache Xerces and Microsoft XML parsers are used as concrete examples.
XML provides a family of technologies for navigating XML structures and addressing subsets of those structures. This chapter looks at XPath, XPointer, XInclude and XBase as a suite of technologies used to create both intradocument and interdocument relationships.
XML Schemas bring the modern conveniences of running water and electricity to the uncivilized world of pre-schema XML. Prior to the XML Schema language, XML supported structure but not type. Schemas bring a type system to XML that reflects the past 30 years of software engineering practices. This chapter looks at how that type system works and how it is described.
XML has a programming language and that language is the XSL Transformation language (XSLT). This chapter looks at how XSLT joins the ranks of languages such as Perl, Active Server Pages, and Java Server Pages by allowing exemplars of a text file to be adorned with executable instructions.
In its rush to attack every software problem with the XML hammer, many XML-based applications are reinventing paradigms and techniques that have already been codified in the world of component integration. This chapter looks at the role of XML as a software integration technology, first by looking at the state-of-the-practice in the pre-XML world, and then looking at how XML can replace large chunks of technology that delivered less than promised.
The Infoset is the most important yet least read XML specification. This appendix contains a reprint of the most recent public draft of this specification.
The serialization rules and abstract data model rely on a set of productions defined in the Extensible Markup Language 1.0 and Namespaces in XML specifications. This appendix contains the complete list of productions sorted both by name and by production number.
The chapters in this book attempt to show only the smallest possible XML or code fragment needed to make the point. This appendix contains larger examples for readers looking for additional context.
The authors collectively would like to thank Kristen Erickson, Jacquelyn Doucette, John Wait, Kathy Glidden, and Carter Shanklin for shepherding this book through Addison-Wesley. The authors would also like to collectively thank all those who read drafts during the production of this book. These very helpful folk include Bob Beauchemin, Tim Ewald, David Ezell, Dave Hollander, Gopal Kakivaya, David Megginson, Noah Mendelsohn, Chris Sells, and Dan Sullivan. Any errors or flaws that remain are of course the responsibility of the authors (most likely Don).
Don would like to personally thank the always-enthusiastic Aaron Skonnard for initiating the project and acting as spiritual (cheer)leader and John Lam for causing me to look into the blinding white light that is XSLT. This broth was definitely not spoiled by the presence of your culinary expertise.
Thanks to Dave Reed and Greg Hope for roping me into the SOAP project back in March of 1998. I can't believe how much that project has impacted my professional life. Thanks to Bob Atkinson and Mohsen Al-Ghosein of Microsoft for their early dedication to the SOAP cause, and to John Montgomery, Satish Thatte, Andrew Layman, and Henrik Fredrick Neilsen for sneaking SOAP past the 24,000 owner/employees at Microsoft, all of whom wanted to get their fingerprints on the spec.
Special thanks to my friend Gopal Kakivaya, who forced me to rethink my assumptions about XML, COM, and type more times than I can remember. Numerous discussions with Keith Brown, Tim Ewald, Michi Henning, Noah Mendelsohn, Chris Sells and Henry Thompson provided invaluable context for that exploration.
A wet, sloppy thank you to David Baum and his staff, both for providing me with tons of support during an especially difficult time and for letting me hang up the virtual shingle that read "The Law Offices of Donald F. Box" at least for a day. This book would never have been completed if not for the sanctuary (and oversized bathtub in the Governor's Suite) provided by Roger Evans and Luc Bramlett.
Thanks to Michael Longacre, Joanne Steinhart, and the late Joe Flanigen andEric Maffei at MSJ for looking the other way as I slipped deadlines during the production of this book. Thanks to the staff at DevelopMentor for ignoring me while I remained dark for month after month and for providing the most supportive working environment I could ever imagine. Special thanks go to Mike Abercrombie, Helga Thomsen, Barbara Box, Maggie Smith, Ron Sumida, Martin Gudgin, Tim Ewald, and Judith Swerling for proving that it takes a village to be Don Box.
Finally, the growing number of Boxes that provide a larger and richer context for all of this have once again proved that there is life beyond the Infoset. I am not worthy of their love and dedication.
Aaron would like to personally thank his wife, Monica, for the patience and support that she willingly gave to this project. I would also like to thank my children, Michelle and Michael, for sacrificing some of their time with Dad. I can't express the joy that each of you bring into my life.
Thanks to my parents, sisters, and in-laws for their endless support and sincere interest in all that I do. Thanks to Kristin Erickson and Addison-Wesley Professional for their hard work and patience. And thanks to everyone at DevelopMentor for your individual contributions toward such an innovative and rewarding environment.
And finally, thanks to my coauthors for their dedication to this project and their never-ending passion. A special thanks to Don Box for his continual guidance and inspiring personality.
John would like to personally thank Aaron for coming up with the original idea for this book, and Don for shaping the story that ultimately became this book. I found that I took far more away from the experience than I put into it. Thanks, guys, for making it such a great experience.
A great big thanks goes out to all of the folks at DevelopMentor, a first-class organization all the way around. Thanks for making it possible for me to do the things that I love to do.
I would like to thank Michael Leneghan for his support and encouragement during and after my transition back to computing. I would not be where I am today without your help. Gracias.
I would especially like to thank Professor Ronald Kluger for his mentorship during my tenure in grad school. You taught me how to think critically and write clearly. Your impact is clearly felt throughout the pages of this book. Thanks.
To my parents and my brother, Thomas, who have been with me since the beginning, a heartfelt thanks for taking an interest in my work and in my life. And finally, thanks to Carolyn for her love, support and encouragement over the past 12 years. We made it!
Manhattan Beach, California