Use CodeSynthesis XSD to generate XML bindings

[nickerso]

The current proposal from Randall (@codecurve) is to use the CodeSynthesis XSD tool to generate XML bindings for the serialisation and deserialisation of libCellML objects into and from XML.

[nickerso]

see pull request #33

[nickerso]

As discussed previously, I'm not convinced this is a good approach to use. As the implementation of the use-cases progresses we will need to evaluate if this approach is suitable for the long term benefit of this project.

[agarny]

Just out of curiosity, what is the motivation for CodeSynthesis XSD? I had a quick look at it and the concept seems interesting, but I guess it would have to be seen how it actually performs.

More importantly, however, is that I can see that CodeSynthesis XSD is released under GPL v2, which is clearly not business friendly. In fact, they make it very clear on on their license page. So, in the end, I would simply stay away from CodeSynthesis XSD, if anything for that reason alone.

[jonc125]

For our use case we'd be covered by their FLOSS exception so that isn't an issue. It's the same thing that allows us to use it in Chaste.

[codecurve]

Reason for using CodeSynthesis XSD: Working with XML via generated bindings saves time (probably months).

[nickerso]

The main issue with this approach, besides that some of us feel it is overkill for the requirements of this project, is that it is not clear how a schema-based approach is going to work as we move forward with CellML 1.2 Core + Secondary specifications. We have adopted this approach currently with a view to re-evaluate its usefulness once some of the more useful use-case are implemented and we see how the code base evolves over time.

[jonc125]

I suspect the main difficulty with an XSD-based approach might be in handling MathML, since when you're actually working with the mathematics having to deal with the MathML element structures is a pain!

[nickerso]

good point regarding the MathML. I know Randall's previous tests with this approach have not included MathML at all, so it will certainly be interesting to see how things evolve.

[codecurve]

Actually, I have already done some work with content MathML and CodeSynthesis, and I think it can be done, however, the content MathML XSD is very complex, so it would be necessary to either first create a pruned version of the content MathML XSD, or alternatively, work with the CodeSynthesis maintainers to support the content MathML schema "out of the box". That said, if content MathML bindings get done without CodeSynthesis, there still are benefits to using CodeSynthesis elsewhere in LibCellML. Note also that it is the benefit of using XML bindings generation that is desirable, as far as I can tell, CodeSynthesis is the best open source tool for doing bindings generation.

If we do create XML bindings and processing utilities for content MathML, it would be hugely beneficial to a much wider community, and so it would be best done as a separate project. In that case, it is likely that we would get involvement and contributions from a broader community than just the CellML community. It would also mean that the focus would probably have to be on MathML 3, since I doubt that a project to create a library for processing MathML 2 (which is fairly outdated now) would gain as much interest. Thankfully, software that can process MathML 3 will be able to process MathML 2 due to MathML 3 incorporating MathML 2 in a compatible manner.