Previous Table of Contents Next


CHAPTER 4
Plan in the Present, Save in the Future

Now that you’ve seen what XML looks like and the enormous power it gives the designer, it’s time to look at the implications of what’s been covered so far. XML allows designers to create their own tags. Cascading Style Sheets can combine very nicely with XML to let you define your own formatting language. You can do almost anything you want without having to pay attention to what someone you’ve never met said on a committee years ago in a distant land. XML is an extremely powerful tool, capable of amazing things. Unfortunately, XML is something like a chainsaw—incredibly powerful, capable of getting the job done without too much effort, and amazingly dangerous. Chainsaws demand regular maintenance and skilled users or they inflict tremendous damage. XML (probably) won’t cause you bodily harm, but it can inflict tremendous damage on poorly thought-out projects.Users who thought they could just start it up and go to work without learning about the tool and how best to apply it are in for some dark days.

XML has the potential to become the worst disaster yet to hit the Web. Sites composed of poorly written XML may look okay on the surface, but they will rapidly deteroriate into maintenance nightmares that require small armies of developers who must sort out the incompatibilities between pages on the same site. Millions of people may choose to spend their time reinventing the wheel, wasting time that could have been spent coding productively. Companies may continue to waste thousands of dollars converting information from one poorly thought-out system to another. HTML isn’t always beautiful, but badly written XML can be much uglier.

XML is about much more than creating documents that look good on someone’s screen. Unfortunately, that means that many more people must be involved in the process. When the Web first began creeping into businesses, it usually started in whatever group or person handled computers and networking and migrated slowly toward marketing and design. Even though different divisions of a company might all contribute to a Web site, their areas didn’t all have to look identical, and data could arrive in different formats. Web applications so far have been mostly driven by relational databases, both of which have their own format and structures. XML promises to unify all these different pieces, making the transfer of information between divisions and departments much smoother and the transfer out to the Web much easier.

If you just want to use XML to extend your existing Web development toolset and have no interest in document management, you can, and the rest of this book will show you how. Keep in mind, however, that you’ll be losing many of XML’s advantages and still be spending your time building converters and hand-coding pages, much as you were with HTML. The ability to create your own tags is exciting, but it’s only the beginning of what’s possible. Additionally, you’re exposing yourself to larger problems in the long run if you’ve written and used your own DTD for documents and your company develops a new, incompatible one that you are required to use.

Making this process work requires cooperation from many parts of an organization or even an industry. SGML has been mired down in committees from its very beginning, and XML will probably inspire many committee meetings of its own. This organizational quagmire doesn’t have to mean endless meetings and continual reorganization or perpetually slipping release dates for the new company Web site. XML can greatly enhance collaboration, but it takes a certain amount of collaboration to get things moving at the beginning. Developing an XML DTD doesn’t have to be a companywide initiative, bringing together hundreds of people from across a firm, but involving more people than the Web development staff is an important first step.


Previous Table of Contents Next