As I've mentioned in the past, I'm the principal UK expert (yes, the "PUKE") for ISO TC68/WG4, the ISO working group that has produced an updated version of the ISO 20022 standard. ISO 20022 is standard for defining messages based on definitions in a central repository, with a focus on banking and finance. Those of you whose are involved with financial messaging via the SWIFT network will have used ISO 20022 messages whenever you use one of the XML "MX" series messages. WG4 has produced a 2009 version of ISO 20022; it is currently a committee draft which has gone to TC68 for an international vote, so it is not yet an approved version; the current approved version is the original 2004 version.
My particular interest in ISO 20022 is in the part that describes how to generate XML Schemas from UML models. I like the repository based approach where you can share components between related messages, but don't have to implement that sharing at the Schema level, with includes and imports. ISO 20022 has one Schema file per message, and that makes life easier than if you have to get people to set up a hierarchical directory of cross-linked Schemas correctly.
I wrote an XML Schema generator for the current 2004 version of ISO 20022. That generator works with XMI (UML in XML) files produced by Enterprise Architect (from Sparx Systems), and is implemented as a series of XSLT scripts.
For the new 2009 version of ISO 20022, the good people at MagicDraw donated licences for WG4 to use their UML editor, and so MagicDraw is the UML editor that was used to develop the new metamodel and UML profile. For this reason, for my new implementation I decided to target MagicDraw (I might support other UML editors too, later, depends on how many requests I get).
I decided to continue with my previous approach, working from the XMI, this time using a mix of XQuery and XSLT. XMI is a rather generic XML format that can be hard to read and understand, so I consider it error-prone to try and generate XML Schemas from the XMI directly. Instead, I distill the XMI into a much simpler XML format which reflects the structure of the ISO 20022 metamodel, an "XML DSL". I then process that simpler XML file to generate Schemas or anything else. So, the plan was to use an XQuery to generate the simple XML, and then XSLT to generate the Schemas (there are some things that are easier in XSLT than XQuery).
However, it turns out that the latest XMI 2.1 standard is loose around how UML stereotypes (user annotations) are represented. So, after some failed attempts at "reverse engineering" how MagicDraw represents stereotypes in XMI, I decided I needed a different approach. Instead, I am using the MagicDraw Open API to read the contents of an ISO 20022 UML model. This means I need to be using a Java program, or something that runs on a JVM.
Java itself isn't great for XML, in as much as the code tends to end up rather more verbose and unreadable than it need be. I tried Groovy, which has some reasonable support for XML, but moved away from that because the XML support is incomplete. It seems that in a number of languages, the people who implemented the XML library didn't really like XML, so they decided to only implement support for the parts of XML that they thought were worthwhile. For users, that causes nothing but problems.
What I am currently using is Scala, which is convenient because you can just start typing XML as the value of a variable in the middle of a program, and Scala knows what to do. I've now written the code to generate the simple XML format. It hasn't been as easy as it should have been, because Scala support in IDEs is still weak (I use Intellij), and because Scala's integration with Java is good but not as good as it could or should be. For example, Scala avoids the use of null values. It does have some support for them because it needs that to work with Java libraries. However, at times when Java code would give me a null pointer exception, I find my Scala code just hangs, leaving me with a lot of searching to do to find what went wrong and where. Still, the code is more readable than Java, and things can only get better, so I'm planning to stick with Scala for this.
Once I have XML Schema generation done, the next thing to look at is ASN.1. ASN.1 ("abstract syntax notation") is an ISO standard for designing messages that predates XML, and has been most widely used in the telecommunications industry. Note that I wrote in a previous post that ASN.1 was the format used for ISO 15022 messages (more-or-less the predecessor to ISO 20022). That was wrong, I want to point out; somewhere along the line I got the wrong idea, and in spite of my saying it in a number of WG4 meetings, only recently did someone from SWIFT point out that I was mistaken.
Anyway, WG4 has added support in the 2009 version of ISO 20022 for ASN.1 as an alternate message syntax to XML Schema. Now, ASN.1 itself is actually multi-syntax. There are a couple of binary encodings it supports, plus there is a more recent XML encoding. The ISO 20022 profile of ASN.1 has been constructed so that, as closely as possible, an XML message that is valid according to the XML Schemas will also be valid as an XML encoded ASN.1 message, and vice-versa. Since ASN.1 messages also have a binary encoding, this new ASN.1 support means that ISO 20022 will have an official binary encoding as well as the existing XML encoding. It will be interesting to see how the usage of XML versus binary ISO 20022 messages goes over the next few years; banking and finance applications have size and latency challenges for which plain-text XML often isn't suitable.
I should be able to generate the ASN.1 grammars for the messages from the same simple XML that I use to generate the Schemas. Doing so will show that the simple XML genuinely decouples that back-end code generators from the format of the input UML model; that's something I need to have the possibility to support UML editors other than MagicDraw in the future.
If any of this interests you, either ISO 20022 or my work on Schema and other generators for ISO 20022, feel free to get in touch.