XML: Whines and Battles

XML: Old whines in new battles

By Peter Flynn ([email protected])

Will the Webs new markup grammar repeat history?

Abstract

In the rush to learn, implement, and profit from XML, many of the questions being asked are the same ones which came up when HTML was new. Can we learn from the lessons of HTML and make the Web a more productive and reliable resource for providers and users alike?

Since its formal launch last December, XML (see XML and HTML) has had a lot of support from software vendors and authors, content providers, service providers, and even the Sunday papers. However, the pressure to adopt XML is having some interesting side-effects, and not all of them are desirable. Its still too early to say for sure, but it looks like some of the early misunderstandings with HTML are about to surface again. Part of the technique for staying ahead of the posse is therefore to know the answers (or at least to avoid asking the wrong questions).

XML and HTML

XML, if you havent come across it yet, is a new system for defining how you can write Web files. Its a sawn-off version of ISO 8859, the standard used to define HTML and hundreds of other business applications.

Full ISO 8859 (SGML) is quite powerful, and can be fairly heavy going at times: it has a load of optional bells and whistles. By contrast, XML leaves out all the optional bits, so its easier to write programs for, but it keeps most of the useful bits, so you can use it to design your own markup language instead of being restricted to HTML.

XML has some significant benefits for content providers as well as designers:

You can use a custom tagset and document structure for different classes (types) of document, which describe much more accurately what you are doing.
You can use the markup to do some of the donkey-work for you, like handling repetitive text or having multi-way links.
You can use XSL stylesheets (with CSS) to achieve much greater formatting accuracy and control.
You can use XML for all kinds of content applications HTML was never designed for, like carrying manufacturing parts data or an accountants balance sheet.

Some side-effects of XML

However, along with death and taxes there is a third certainty in life, and that is if you want to use a new technology while its still new, you have to learn it, usually from scratch. There arent a lot of books on XML out yet, but the number is growing (half a dozen at the last count). These are high quality books, although most are pretty technical. Remember how things were when the Web was still new? Pointy brackets and plain-text editors and having to learn why <H2> made more sense than <BIG><B>? Now when a new Web user wants to write that first home page, product announcement, or golf club news-sheet, there are graphical page-design packages to help with the layout, and Web-based validation services to test it all against various browsers.

The learning curve is here again: people who have been creating Web pages without really ever seeing much of raw HTML markup will need to come to terms with the stuff in pointy brackets if they want to get in on the ground floor of XML. This time around, the apparent drawback (there is no predefined HTML to help you) is the actual benefit (XML lets you roll your own markup).

Things ought to be a bit different on the software front, too. Long before the pixels were dry on the draft XML spec, there was XML software being developed and XML documents were being written. Almost a year before the final spec was published, there was a suite of XML files to test against, and even a full XML application (CML) complete with a browser (JUMBO). Right now were armpit-deep in software for the technology which underlies XML: every first-year computer science student is writing an XML parser in Java; every industry, trade, or business association has someone writing at least one application (the list on the SGML/XML Web pages grows almost daily); most of the major SGML vendors have XML-compliant versions of their products; and there are some wonderfully good public domain software toolsets. Whats still missing is some of the glue to hold the bits together, and the end-user software.

Comments are welcome

URL: https://www.webreference.com/authoring/languages/xml/questions/