XML is truly wonderful stuff. I've spent the last 20 years (more or less) working
with markup and plan to spend the next 20 (indifferent universe willing) doing
the same.

However, there are some major fallacies that are worth bearing in mind in order
to maximize the very considerable return on investment that you can get from
XML. There are many traps for the unwary. There are many aspects of the technology
that you probably will not come across during standard training or standard
reading materials that are well worth bearing in mind.

As a document-oriented person, I am biased of course. If your use of XML is
purely database-oriented some of these fallacies won't be relevant to you. So,
YMMV is the order of the day.

That said, here are my favorite XML fallacies (in no particular order):

Fallacy 1: All documents have a single, true, unchanging, hierarchical,
semantic structure that can be identified and turned into an XML schema.

Fallacy 2: An XML schema can capture that structure perfectly, splitting
documents crisply into those that are valid and those that are not.

Fallacy 3: All documents have a single, unique semantic "type".
It is just a matter of finding it and giving it a name.

Fallacy 4: XML tags can capture all you need to know about a document
and make it completely self describing.

Fallacy 5: Creating an XML schema for a document type is the hard part.
Everything else is just programming and configuration of off-the-shelf XML tools.

Fallacy 6: There is business value in having your own custom tags all
the way down to paragraphs and bulleted lists etc.

Fallacy 7: XML tags do not cost money because they are very easy to
create.

Fallacy 8: One document schema is all you need to cover the entire life
cycle of any given type of information, from creation through to publishing.

Fallacy 9: Documents go through their entire life cycle conforming to
the one true schema. That one true schema can be deduced by analyzing a subset
of previously created, finished documents.

Fallacy 10: XML schemas will not atrophy into structure-less controlled
vocabularies as changes are made over time.

Fallacy 11: When you find a document that does not fit the XML model
you currently have, it is perfectly okay to just loosen the model until it fits.

Fallacy 12: There are important differences between element type names
and attributes when it comes to capturing the meaning of information.

Fallacy 13: Document validity is a black and white matter of (non) conformance
to a schema.

Fallacy 14: Normal human beings are always more productive in grammar-driven
structured authoring environments than they would be in "loose" word
processors.

Fallacy 15: The semantic structure of content always exists before the
content itself has been created. You can start with the perfect end structure
and just start pouring the content in, filling in the blanks as it were.

Fallacy 16: Zipf's law does not apply to XML element types.

Fallacy 17: It is only a matter of time before structure-controlled
XML editors become as easy to use as word processors.

Fallacy 18: It does not make sense to think of a word processor as a
XML tool - even if it stores its data in XML. The XML produced by WP-style tools
is nasty and brutish and devoid of any semantic value. It is not truly XML at
all.

Fallacy 19: It is only a matter of time before browsers can do all sorts
of clever things with XML on the client side.

Fallacy 20: The only valid way to capture and publish semantic information
in documents is with tag names. Putting that sort of information into attributes
is a hack.

Fallacy 21: The XML namespaces specification is very small and therefore
cannot be the cause of significant extra complexity in the XML processing tool-chain.

Fallacy 22: Nesting elements is the only legitimate techniques for representing
hierarchical structure in information.

Fallacy 23: There are only 23 fallacies associated with XML.

ITworld.com

• Email
• Print
• Share
  • Slashdot
  • Digg
  • Stumble
  • Reddit
  • Newsvine