When I started working in the IT in the far 2004 - yes, I'm still relatively young - there was an era when describing anything in XML was a must, even if could had been avoided :)
Then, when JSON came out, the bigger part of that people blindly switched to the new format after reading few blogs pages mainly because "it is faster to parse".
Of course, no doubt about it, but... are we sure they were good on describing data in XML?!?
For what I learnt, to write a good model, the designer has to keep in mind no just data to be modeled, but how to write an efficient processor as well.
Follow below a serie of horrendous mistakes I met during my - even short - carrer.1. Properties
A customer in a TLC company gave me a REST API set to integrate, it described a collection of objects and looked, more or less, like:
And I don't think that deserves any comment.Update
and realized that the processor parse the text to extract different parts... please don't think I'm pedantic, but since we are using XML, what's the reason of writing a parser inside the XML parser, when setting attributes would have been:
2. Nested elements
- human friendly: I would understood the attributes semantic earlier;
- easier to parse: just get the attributes values.
This is fun as well. The same customer had a legacy application that was configured with a proprietary XML dialect - and no, not chances to get an XSchema nor even a DTD - that looked like
<properties a="1" b="2" />
So when he decided that was verbose enough, replaced the current descriptor with a JSON one:
Do you think that customer was in the position to complain XML or the use he did of XML?!?3. XML to transfer binary data
People used to transfer binary data inside XML did never understand that putting Base64 encoded data inside XML forces developers to write not one, but two parsers, Base64 elements should be decoded using en efficient incremental writer - or you want to read the whole text and then decode it?!?
No alternatives for binary data - treat them as they are, just attach metadata descriptors!4. No legacy XSchemas/DTDs
The good and dark side of XML is its eXtensible nature. Anyone can invent his own format to describe the domains... oh, how powerful it is!
OK, no standards match with your needs and you have to model you domain... But if you don't provide at least a DTD, how can you [...] pretend people continue modeling data by samples?!?5. Did you know XML has attributes?
preface: I'm an addicted fan of Apache Maven and I ahve to say a big 'thank you' to all the guys I have been maintaining it, but thumbs down for the pom.xml format. It never uses a single attribute.
Do you complain Maven's pom is verbose? No objections, but NOT ENOUGH to complain about the whole tool.
So, my suggestion for my few readers: don't be superficial, study in deep technologies before putting systems on production, be critic, don't accept blindfolded one format or another just because Mr. XYZ wrote on his blog "X rocks, Y sucks", invest more time on optimizing your infrastructure and less on stumbling on affirmations like this :)