Editing XML: The Good, the Bad, and the Ugly (1/5) - exploring XML

Editing XML: The Good, the Bad, and the Ugly

If you, through reading this column or otherwise, became an avid backer of XML technology, you
face several challenges in adopting it: Immature and missing tools, short supply of
XML-knowledgable colleagues, confusing and contradicting industry initiatives.
And it all starts with the most fundamental question:

How to safely and comfortably edit XML documents?

Depending on your expectations for editing comfort and the depth of your pockets
this question has several answers. In the XML jungle we distinguish the following species:

The Purists

The purists avoid all special-purpose editors. They know their DTDs by heart and match
opening and closing tags in the back of their head, up to ten nesting levels deep at
least. Trained by programming languages with curly braces or begin-end pairs they
benevolently smile at pointy brackets, until they need hours to get their one
page XHTML document finally accepted by the W3C validator.
The largest family within that species relies on:

Microsoft Notepad and Internet Explorer

Internet Explorer 4 and 5 check XML documents for well-formedness and display them in a
textual tree structure with expanding and collapsing branches.

Errors are flagged in the browser window, together with the offending data and the
corresponding line number:

Any text editor will do the job, and one with line numbers is extremely
helpful when you tend to confuse tag nesting levels. The new Mozilla browser
currently lacks a default stylesheet for XML data, so it can only be used for
proof-reading with an CSS stylesheet tailored to the XML document type to be edited.