XML Editors

We've been doing some work with FpML (Financial Products Markup Language) which is an XML standard for describing trades between investment banks, swaps, futures etc. Its a complicated standard in the form of an XSD (XML Schema). So producing XML that is valid against the FpML schema is not entirely straight forward.

The best approach we found was to prototype the XML messages by hand before writing the code that would do this automatically from our front office system. This was reasonably straight forward where we had examples to copy, but suitable example only covered a few of our use cases, so we had to start designing some of the XML from scratch.

We started off trying to use notepad to create the XML, but this was a non-starter, tiny errors would take an age to track down and it's not what anyone would call a fully featured editor. We downloaded and started using Microsoft's XML Notepad, but it was awkward to use, and didn't seem to have any knowledge of the schema, so the validation was very limited.

Eventually one of the team found Liquid XML Editor, this is a free text based editor that is schema aware, and even shipped with the FpML standards so when we opened our XML file it automatically loaded the schema, and told us about our errors.

As well as validation, the editor also uses the schema as a source for the intellisense and documentation, which is pretty powerful given the complexities of the FpML standard. We ended up playing with a number of XML Editors, and this was the only one that could cope with the way the complexTypes are defined within the FpML standard.

The intellisense and validation helped a lot when trying to build up our XML prototypes, but what was still lacking was a feel for the structure of the FpML entities. We tried looking at the FpML schemas, but these were all but un-readable in code form. We eventually stumbled on a feature within the XML schema editor, that allows you to create HTML documentation from an XML Schema, we later discovered this documentation was already online see FpML online documentation. This gave us a good feel for the shape of our target XML document. We then used Liquid XML studio's XML editor to finish prototyping our XML documents.

Our final problem was the target system could not cope with the XML documents we produced. Initially we figured our XML was wrong, but after running our XML through a number of validation applications, and digging through the XSD standard we concluded the error was in the target system. After a lot of hassle with there support team, we eventually figured out a solution which involved adding in a few additional elements. This effectively made our XML non-FpML compliant, but it fixed the problem we set out to solve. We left a load of comments in the code and XML to explain the issues, but I've seen this kind of thing to many times where a standard is 'interpreted' by a number of 3rd parties and the resulting inconsistencies end up causing issues for years to come. Good tools, especially in the XML validation area should start to reduce this problem in future but its unlikely to resolve it altogether.

We are now looking at the feasibility of setting up an XML firewall on all our service clients. Basically anything that comes in must have an associated schema and it must validate against it. If it fails validation, then it doesn't get anywhere near our system. This seems like a great idea in principle, but I recon we'll end up bouncing so much traffic, we'll be forced to take it down…time will tell.