As mentioned in an earlier article I’ve written an XML extractor from a SOAP-Response XML to represent the data with iText as a PDF. The XML-Extractor was big, bogus and obtrusive. Lately I’ve got to know XMLBeam which does the same thing I’ve created — but it is more lightweight and reusable. So I switched from my implementation to XMLBeam: removing around 8 classes (average 100 LoC each) and substituting the whole functionality with 136 LoC.
Let’s see how it happened.
The problem with some articles are that I get the idea of them as I work on a specific topic however I end up writing the article itself weeks or months later. This article has the same issue: I thought about it at the middle of may and now I’ve forgotten why I wanted the Google App Engine (GAE) to be a part of the topic.
Let’s see, what I get at the end.
Recently I got a question from one of our customers: how do we validate XMLs against their XSD definition? Because we offer an XML based interface to our system, where the customers have to provide the XML data which we read into the system — and naturally we give an Exception if the provided XML does not match our expectations (which is defined in the XSD naturally).
So we suggested some on-line resources where you can put in the XML and XSD and validate them and we mentioned the capability of open source tools too. After a few days I got an answer that they are not able to validate our example XMLs against the provided Schema so I should give a better hint how we do that. And this is why I created a simple Java application which takes some parameters and validates the XML against the XSD. After this, I looked up what could be done in this topic with Python.