[
Lists Home |
Date Index |
Thread Index
]
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@midwestiso.org> 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
|
