>There have been some comments from the modeling community picking on XML. XML should not be blamed for our own laziness, or bad habits. Use the right tool for the right job. The problem with XML is that in many cases it isn’t used correctly, or used in the place when it doesn’t need to be used. Sometimes a Java property file is much more efficient representation of configuration data than an XML file. Use the right tool for the right job.
I’ll argue that XML is much more human readable from a semantic stand point than some other representation formats that are really designed for machines, not humans. Comma Delimitted, EDI, or other formats that hide the semantics, or need a guideline to understand what particular data means at a certain position isn’t human readable. XML file formats can be horribly designed, but that isn’t XML fault, that is the designers fault.
Most notablly, tools that serialize Classes to XML files, are horrible from a human readable standpoint. If you see elements with the names of a A, CNT, SomeValueHere, the fault is in the serialization of the class to a XML representation. I agree that these files aren’t human readable. However elements and attributes named correctly can be very human readable, but then comes the other argument….XML isn’t machine friendly. It’s too robust. Again, it can be, but don’t blame XML for choosing to represent it or use it when it shouldn’t be used.
From a data exchange and markup standpoint, I’ll say that XML hits the correct balance between potential human readability, and machine processing. Having a common parser is not necessarily bad, if it fits the need. Why invent a parsing framework unless you absolutely have to?
Use the correct tool for the correct job. Modeling is a great thing, but a bad Model is going to have a bad representation no matter what format you choose. The fault lies in ourselves, not in any particular format.