XML is one of many things in which I have a love-hate relationship. There are lots of very good reasons why it continues to permeate the insurance industry. Technology in the insurance space (and those of us who provide said technology) continue to create systems that are reliant on XML as a key underpinning. Here’s a few key facts that I’ve learned in my years of dealing with XML that might help someone else who is just beginning to put their toe into this world.
Continue Reading from eInterpreter...
According to w3schools.com, XML is a software and hardware independent tool for storing and transporting data. It was designed to be self-descriptive (meaning that reading the XML describes the data it’s meant to convey) and XML is extensible so that it can be changed from time to time. Sounds easy enough, right?
In my experience XML can be very useful but only if you follow a few key rules. The first rule is that it must be self-descriptive. In general, tag names should be as descriptive as possible and grouped together in a logical format. Another element of being self-descriptive is that any XML must be accompanied by a complete and valid XSD. XML doesn’t specify field type (meaning string, float, binary etc.). The only way that a consuming application can know what type is acceptable for any given field is based on the type information supplied in the XSD (XML Schema Definition – used at design time). Another key component that must be specified correctly in the XSD is whether a given field is meant to repeat (as an array) or can be completely missing. Many of my struggles over the years with XML has been a result of an incomplete XSD. It’s very tempting to go to one of the many online tools and generate an XSD from any given XML file, but if the original XML file isn’t complete and fully descriptive of all the combination of data that can appear – trouble will follow. My advice to you is to avoid the temptation to craft your own XSD and work with your colleague who is generating the XML to build a comprehensive XSD from the beginning.
The second rule that I’ve learned is that XML is great for what it was intended, namely transporting data, but not great at other tasks. This is the case where the right tool for the job makes all the difference in the world. My job involves the creation of documents. XML is a great mechanism to use to transport the data structures needed to generate a document via a web service call. However, XML is an inadequate format to try and describe the physical output attributes of a document. I’ve seen developers try and use XML for this purpose and it doesn’t work well. If you need to describe the attributes about how a document should look, then move to something like HTML which was intended to display data with a focus on how the data looks. Use XML only in situations where you need to exchange data between two systems. As soon as your focus changes from exchanging data to manipulation of the data’s appearance – you need a different tool.
My third rule is to maintain as much independence as possible. There are situations where your XML will become very specific to a certain device, program, operating system, browser etc. I really like to think about any XML file as a layer of abstraction from the underlying data source. With some thought and planning, schemas developed to exchange data between system A and B can be repurposed to exchange data between system A and C. Acord has adopted this thought and developed many standards around XML data exchange. Put some thought into your structure and tag names with an aim to have your structure be as reusable as possible. Think about the data that you are exchanging as topics or domains and model it this way. Yes – it requires more thought and design at the beginning but you will end up with a more independent and reusable product in the end.
In summary, XML is a good tool in your bag of tools. Structure it properly and use it judiciously and you will find it serves you well.