[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: Validation - Is it worth it ?
Hi Fraser, On Sat, 2006-02-11 at 19:23, Fraser Goffin wrote: > All of this is exacerbated by a relatively weak versioning model for XML > schema. We are giving this a lot of thought at the moment (all suggestions > welcome :-), in combination with trying to protect our internal systems from > the impacts of changes in the external standards (e.g. an internally managed > canonical data model - blimey, I've lost count of the times we have tried > things along the lines of Enterprise data Model - and failed !). We've also spent quite a bit of time looking at various versioning strategies for our SOA. I know that some people on the list have seen an earlier incarnation, but in July, we released an updated rig0006 (http://sdec.reach.ie/rigs/rig0006/), which attempts to provide a framework for versioning along with some usage guidelines and a worked example or two. Maybe it will save you some pain... :) The *extremely* short version (sorry, I tried to think of some other word, but this is the 3rd time "version" came to my mind, so please just groan and forgive--no pun intended) is: - XML schemas are versioned using namespaces - XML schemas use the "salami slice" model for element definition - Backwards/forward compatible changes are possible through a defined extension point & must-understand attribute mechanism and the concept of a version family of schemas - Incompatible changes to a schema resulting from structural changes, but which are determined to still represent the same semantic concept (e.g. incorporation of previously backward/forward compatible additions of elements in an extension point into "first class citizens" within the schema outside the extension point) result in a new major version number - Incompatible changes to a schema which do not represent the same semantic concept result in a new message type (in our case, a new rigXXXX), and its development will follow the version rules in rig0006. This approach allows both what we term "message types" (complete business messages) and "data fragments" (reusable parts of a message, e.g. the address) to be versioned independently, yet still be sensibly resolved and processed by services performing validation. Services adhere to the rules specified in rig0006 and can make their own determination as to which messages they are willing to process and which ones they reject. It also means that simultaneous support for multiple versions of particular messages and data fragments are straightforward to support via transformation or augmentation. Hopefully, there's something useful for you in the above. Cheers, ast *************************************************************************************************** The information in this email is confidential and may be legally privileged. Access to this email by anyone other than the intended addressee is unauthorized. If you are not the intended recipient of this message, any review, disclosure, copying, distribution, retention, or any action taken or omitted to be taken in reliance on it is prohibited and may be unlawful. If you are not the intended recipient, please reply to or forward a copy of this message to the sender and delete the message, any attachments, and any copies thereof from your system. ***************************************************************************************************
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|