VAST XML Mapping and “strange” decisions


Last week I had a customer meeting with a company that is about to integrate some new features into their existing product.

One of the things they need to do is import information that comes from devices and will be delivered in XML form. We tried a few samples and wrote an xml mapping spec. Things seemed to work fine, but we also found  a few things that I think are quite strange.

It seems like the VAST XML mapping feature pretty much relies on the availability of a public interface for mapped attributes if you don’t explicitly include the getter and setter in the mapping spec. So if you have a mapping like this:


<AttributeMapping ClassAttribute="firstname">
<Attribute>firstName</Attribute>
</AttributeMapping>

And your class has no defined attribute firstname in its public interface, the mapping framework won’t be able to put the data into the object. We’ve seen the data in the DOM structure after parsing the xml file, so this really is an issue wih the XML Parsing stuff in VAST. And no, this is not related to the capitalization of “Name” in the tag name, since the instvar as well as the defined attribute have a name of “firstname” in a working version. We’ve double-checked that…

My proposal for improvement here would be a staged process in deserialization when no getter/setter method is defined in a mapping:

  1. look for an attribute definition with the name firstName
  2. if there’s none, look for a setter with the name of the attribute and a colon

Without this, it’s a bit surprising to see values not being read into the object model although everything looks correct.

I see no good reason for the requirement of a defined attribute in the public interface here.