All structure in an XML document should be indicated through XML tags, not through other means. XML parsers are designed to process tags. They do not see any other form of structure in the data, explicit or implicit. Using anything except tags and their attributes to delineate structure makes the data much harder to read. In essence, programmers who write software to process such documents must invent mini-parsers for the non-XML structures in the data.
For example, in the bank statement XML application we examined in Part 1, a transaction could theoretically be represented like this:
<Transaction>Withdrawal 2003 12 15 200.00</Transaction>
This would require applications reading the data to know that the first field is the kind of transaction, the second field is the year, the third is the month, the fourth is the day, and the last is the amount. In most cases a client application would have to split this data along the white space to further process it. On the other hand, the client application has less work to do and can operate more smoothly if it's presented with data marked up like this:
<Transaction type="withdrawal"> <Date>2003-12-15</Date> <Amount>200.00</Amount> </Transaction>
Here each useful unit of information can be seen as the complete content of an element or an attribute.