xsi:type and XMLSpy support

As always, something new to learn, even when it is something old!  xsi:type enables overriding the default type of an element with a derived type.  See:

Using xsi:type

Using Derived Types in Instance Documents

Another example of how xsi:type is used, in Health IT:  Combining time intervals in CDA and some more related discussion on combining time measurements.

In terms of Altova XMLSpy support though, my understanding is that with XMLSpy Enterprise Edition 2014, rel. 2 sp1, the Schema tab/view does not indicate that there are derived types available for an element's type, nor does it support switching to view the structure of these derived types.  However the Text tab/view does support auto-completing with any of the derived types once we type xsi:type=

Altova MapForce review and tips

Altova MapForce is an interesting tool for creating XSL transformations visually.  Looking past the obvious drag-and-drop nature of the tool, here's my review:

What I liked:

• Promotes the creation of libraries of re-usable functions.  
• Flexible:  Can swap in another XSD without losing mappings, by editing MFD file directly.  The invalid mappings will be highlighted in red for correction

What I disliked:

• Generated XSL is not meant to be tweaked, and it would be very difficult to do so
• No built-in debugging facilities
• No support for non-function-based facilities (e.g. xsl:analyze-string)

Hard to say whether good or bad:

• Everything that is re-usable is function-based, that is, consisting of input (optionally) and an output.  It reminds me of Lisp programming.   

 Tips:

• do not copy and paste functions between MFD files using text editor
• make higher-level functions if find repeating mapping
• If parsing the text of a node which has embedded tags (e.g. <addr>PO Box 123<delimiter />c/o Dave<postalCode>90210</postalCode></addr>), in this case, addr and delimiter, respectively, use the MapForce distinct-values function

XPath heaven and Namespace hell

XPath is fairly easy to learn by example (great examples here) but namespaces in the XML can be maddening when they cause data to be alluded.  Some things to check before you resort to using simple string matching or regular expressions to get to your XML data:

• XPath expressions are case-sensitive
• Indexing is 1-based rather than 0-based, e.g. /MSG.2[1] refers to the first element (not the second element)
• Default namespaces (e.g. xmlns="urn:hl7-org:v3" vs. xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance", the former having a default namespace) requires that you set up a prefix for the namespace if you want to write XPath expressions against the XML content.  Good article about default namespaces 
• When writing XPath expressions where namespaces are involved, you need to prefix each element in the expression (with the appropriate namespace prefix).  E.g. /hl7v3:PRPM_IN301030CA/hl7v3:controlActEvent/hl7v3:effectiveTime is required, /hl7v3:PRPM_IN301030CA/controlActEvent/effectiveTime will not work (there is no inheritance down the branch)

Configuration objects read from/saved to files

For Spring-enabled applications, Spring has a rich configuration scheme, and objects can be fully configured and wired together based on the directives specified.

Alternatively, one can consider defining the application configuration by code, serializing the configuration objects to file as a starting point, and then, as needed, editing the configuration in file format.  When the application starts up, it will read in the configuration, de-serialize it back into object form and the application can work with the configuration.

Not unexpectedly, Spring has a way to set up marshallers/unmarshallers for your application so that it is opaque to the application which XML serialization library it is using.  This makes it easy to swap out for a different library.  I tried three different libraries with Spring and these are my findings:

Library	PROS	CONS
JAXB	"The standard for Java"?	Require jaxb.index file in package's folder Need to annotate class with @XmlRootElement Have to have no-arg constructors even if it is against design practices Doesn't work with Interfaces and cannot de-serialize a class extending from an abstract class
Castor	Popular?	Serializes well but on deserializing, get an error of org.springframework.oxm.castor.CastorUnmarshallingFailureException: Castor unmarshalling exception: The class for the root element 'anonymize-settings' could not be found.; nested exception is org.exolab.castor.xml.MarshalException: The class for the root element 'anonymize-settings' could not be found. For whatever reason, Castor doesn't add the xsi:type attribute on the root element when it serializes.
XStream	Actually works Codebase doesn't have to change for XStream to work with it (no design compromises)	Not popular?  But the library is so simple to use, there is absolutely no learning curve so you don't have to devote a lot of time to it