So the XML data binding wizard makes it easy to read and write XML files. But is there a way to handle versioned schemas in a very graceful manner that I'm overlooking?
So the XML data binding wizard makes it easy to read and write XML files. But is there a way to handle versioned schemas in a very graceful manner that I'm overlooking?
Let's say I get a schema v1, and I make the data binding and my integration. Later the client hands me v2, where say one node is moved deeper into the tree (ie from "head" level to "detail" level).
But if I now create a binding for v2, it will have different types from v1, so v1 and v2 types don't mix in my code.
Is there a simple way to support reading both v1 and v2 files without duplicating my integration code?
Or should I just go XPath and be done?
Let's say I get a schema v1, and I make the data binding and my integration. Later the client hands me v2, where say one node is moved deeper into the tree (ie from "head" level to "detail" level).
But if I now create a binding for v2, it will have different types from v1, so v1 and v2 types don't mix in my code.
Is there a simple way to support reading both v1 and v2 files without duplicating my integration code?
Or should I just go XPath and be done?
Hi how are you?
ReplyDeleteAbout you question, you could make the system itself identify the version, BUT, the entire code that integrates the information must have the correction for each version.
Example:
if integration.version = 1 then
doSomething;
if integration.version = 2 then
doAnotherSomething;
I use this on comunicating with Bank's and other stuff that have a long history of changing versions.
Good luck.
Lucas Chagas The schema does seem to specify a version element, so I can at least detect that. But from what I can see, I might end up duplicating a lot of code due to the mixed types, ie IFooNode from v1 binding is unrelated to IFooNode from v2 binding.
ReplyDeleteAsbjørn Heid I see the point.
ReplyDeleteWhen I use XML, I verify the version and the structure that changes in each version (with a XSD or something [direct on code sometimes]).
On top of that, I still uses some minor tests in the code to verify the version information and the rules for reading specifications.
In the case, tha Brazilian Invoice system has it's versions, I don't realy re-write a new version of the code each time, but with the XML tag for version, I can add ou remove some part the needs changes (or not).
In this case, some tags in the past changed positions just like your example.
My sugestion: in exec time, verify the version and for each, you can use if's in the code for read these modifications, On the other hand, you code can be, sometimes, duplicated like you said with minors modifications.
Luck!
It's not quite the same thing but I've dealt with the same issue w.r.t. integrating/consuming external web services by wrapping them behind my own abstract interface set which then has its own wrapper implementation for each version of web service. Not the prettiest solution but once the wrappers are in place they work nicely to isolate the rest of the system from the version issues.
ReplyDeleteWalter Prins Hm yes, that is one option. But quite tedious to make and maintain, the schema contains 50-100 elements I'm interested in.
ReplyDelete