LabVIEW Idea Exchange

Showing results for 
Search instead for 
Did you mean: 

Version Tolerant unflatten from XML ...

Status: New

It should be nice to modify the "Unflatten from XML" in order to be more tolerant with data evolutions.


For example :


 I used the flatten/unflatten to/from XML to store my applications configuration. It's rapid ... and it works fine ...


But during the software life, you often have to modify the data structures ... and then you'll get problems !

The old XML string is no more compatible with the new data structure ! ... and old config files are no more usable !

( And sometimes only for a single new field !!! )

This could generates problem when you deploy a new version of your program ... and the old config files can no more be reused !  Smiley Mad



So it would be nice to have a more 'Tolerant' XML parser :


  • If the field exists in the old data structure and in the new one, then the field can be loaded from XML.
  • If a new field has been added to the cluster (Data structure), this new field could be initialized with the default value of it's data type.
  • If a field has been deleted in the new data structure, the field in the XML file should be ignored




For the moment the Xml unflatten generates an error when the type definition is not compatible ... and nothing is done.


The new behaviour could be to load "Compatible datas" (by name and dataType), initialize new fields, ignore deleted fields,

and a warning error cluster could be generated  to inform that the XML parsing could be done ... but XML schema is not completly compatible.



Active Participant
This feature exists in dotNet, Java ...
I'd love it !!! sooo smart !
Trusted Enthusiast

Does anyone know what the X stands for in XML?


Currently, there is no "extensibility" in the XML unflatten/flatten functions. I recently decided I wanted to make a configuration file extensible for easier forwards/backwards compatibility, changing from the binary Unflatten to/from String to the XML method instead. I assumed the feature you described was how the function was implemented, but learned it actually was no more extensible than the current binary method (actually, a little worse, since precision is lost in the floating point to ASCII conversion...). Needless to say, that project is shelved for now, sticking to the old way of bundling/unbundling from version to version.

Knight of NI Knight of NI
Knight of NI

> Needless to say, that project is shelved for now, sticking to the old way of bundling/unbundling from version to version.


You could use the OpenG config VIs, MGI's VIs or a flattened class to get a seamless backward and forward compatible scheme (although for classes I think it only goes forward).

Try to take over the world!
Active Participant
This would be awesome!  Very useful for all of my projects!