Code-Level XSLT Integration

Detailed documentation about invoking XSLT transformations from application code is available from the following resources.

javax.xml.transform package documentation in the Java API for XML Processing Specification 1.2, by Sun Microsystems. Online Javadoc documentation, included as part of the Java XML Pack Spring 2002. Available online at

transformNodeToObject method documentation in Microsoft XML Core Services (MSXML) 4.0, by Microsoft Corporation. Online documentation included as part of the MSXML SDK. Available online at

Databases and XML

Using XML with relational databases is discussed in depth in the following resource.

XML and SQL ”Developing Web Applications , by Daniel K. Appelquist (Boston, MA: Addison-Wesley, 2002).

Schema Design

There are several very good resources for schema design. The list below shows a few I recommend.

"ASC X12 Reference Model for XML Design," Type 2 Technical Report, by the ANSI Accredited Standards Committee X12. Available online at While focusing primarily on a semantic architecture for X12's work on XML, this report discusses several syntax-level issues and recommendations regarding document and schema design.

"UBL Naming and Design Rules," by the Naming and Design Rules subcommittee of OASIS's Universal Business Language Technical Committee. Available online at http://oasis- open .org/ committees /ubl/ndrsc/#documents. This is a very good framework for document and schema design. The specification itself generally just defines the approach and doesn't discuss the advantages and disadvantages of various approaches. However, various working and position papers on the Web site may discuss background, issues, and alternative approaches.

"XML Schemas: Best Practices," developed collaboratively by The MITRE Corporation and members of the xml-dev list group , hosted at Roger Costello's xFront site. Available online at You can't go wrong starting here.

"XML Technical Specification for Higher Education," by The XML Forum for Education of the Postsecondary Electronic Standards Council. Available online at This document offers the perspective of a group in one particular industry sector regarding document and schema design practices. It includes discussion of tradeoffs and several examples.

Chapter 13. Security, Transport, Packaging, and Other Issues

Even paranoids have real enemies.

I chose this particular popular observation to start the chapter because I think we need to get some perspective on security. I tend to think that a lot of security worries are way out of proportion, but there are some concerns that you ignore at your peril. You need to take everyone's opinions about security ”including my opinions ”with a few grains of salt. That said, this chapter discusses general issues related to exchanging XML documents with other organizations over the Internet.

Some General Observations about Security

It isn't enough just to create or process XML documents; you have to exchange them with other applications. When those applications are under the control of other organizations, we've moved into the area of what is broadly called "electronic commerce." Since that's the primary focus of my consulting practice, I can't quite close this book without saying a bit about it. However, I won't say very much. Most of the end user target audience for this book, and the people who develop applications for them, aren't given very many choices. They do what large customers or government agencies require. I would like to help you understand why those organizations are telling you to do certain things and, if they do give you any options, to help you make those choices.

At the bottom line, all the choices we have to make about moving documents over the Internet depend on security. So, to set some perspective, here are a few observations and facts about security.

  • It is easier for a store clerk, waitress, or someone who takes your catalog order by phone to steal your credit card number than it is for someone to pluck it off the Internet while in transit.

  • It is easier for someone to grab your credit card number from your mailbox or your trash than it is to pluck it off the Internet while in transit. (How many of you use locked mailboxes and shred your trash?)

  • It is easier for a hacker to break into a system where your credit information is stored than it is to pluck it off the Internet in transit.

  • In over ten years of working with EDI, I've never heard of a fraudulent EDI transmission of business data ”no bogus invoices, no orders to be shipped to suspicious locations. Granted, it is harder to break into the third-party value-added networks used for EDI than it is to hack the Internet. However, without giving away any hints, it's not impossible .

  • The most popular e-mail programs offer support for X.509 digital certificates that support encryption and digital signatures. With all the sensitive e- mails that I exchange and agreements that are confirmed by e-mail, only two of my regular correspondents ever use digital certificates for e-mail.

Are people overly paranoid about security? Probably so, but don't try using that as a defense when you're prosecuted for not securing the confidentiality of personal information about patients or students. And if you try telling that to the folks at Wal-Mart, they'll probably drop you from their vendor list.