Cart
|
[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: XML Versioning
 The articles which Joe has pointed at from David Orchard (plus some updates on his blog) are a good starting point. Its a subject that is hard to get agreement on but these are some of the things that we have found to be useful to consider :- - designing service interfaces and the implementation behind those interfaces to be tolerant of both missing and additional data (sometimes referred to as the 'must ignore unknown (retain/discard) pattern). - remember the point of a providing a service is so that others are able to call it. If you raise the bar too high or make the interface overly prescriptive, customers will go else-where (so: make it easy for people to bind to) - recognise that not all applications that integrate with your service (schema) will necessarily be able to complete the entire potential payload. So consider making most information items optional (except business entity identifiers) - don't include any minor part of a version numbering schem in the namespace (only the major). - do provide extensibility in your schemata. You *will* want to control WHERE extensions can occur and WHO can create them (schema owner vs. anyone else) but without some ability to accomodate local needs your schema will be too brittle and your versioning process will get too close to the 'big bang' change which in most cases is impractical. This is more important (essential) if your schema will be used for external integration (i.e. by your trading partners), in which case you will almost always need a mechanism for carrying data that represents some specific private aspects of those relationships. - Consider whether you need to version every elementary and common aggregate that go into making up your transactional schema. - consider validation as a multi-stage process (structural, value-based, partial/targeted - technologies like schematron, NVDL may play a part) - code lists (aka. shared reference data / controlled vocabularies). You may want to consider removing some/all of these from schema (at least those that are large/highly volatile) to reduce schema churn. You will need a separate mechanism to be able to represent this data and validate values within instances. Take a look at UBL 2 proposals. - Tim Ewald has some interesting ideas on his blog about schema versioning (they basically amount to - minimise the instances where you need to change the namespace - good advice) - you will need policy and/or some form of governance model to ensure schemata are being constructed in a compliant way. This is sometimes called NDR (naming and design rules) but reflects the practices expected of implementers in using your schemata. Fraser. On 21/07/06, Edgardo Luzcando <ELuzcando@m...> wrote: > > > > Could I get some recommendations on good reading about XML versioning? I > continue to struggle in choosing the "best" way to do this. If anyone has a > good do's/don'ts list I would appreciate it. I am mostly concerned with > Schemas, but the concept I am looking for is generic. > > > > Thanks, > > elf 
|
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
|
|||||||||
