Cart
|
[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] RE: Schema Extensibility
Hi Fraser,
Like you I have kept thinking about the previous thread. I work for the
Dutch Justice Chain, where we use an UBL-like schema set (though the actual
vocabulary is quite different) and we are struggling with those very issues
at the moment. Some comments / opinions:
| I guess the thing that I am still mostly undecided about is
| to do with whether to allow for schema extensibility (using
| xs:any together with the 'sentry' approach proposed by David
| Orchard (and others) or whether this is a recipe for an
| uncontrollable vocabulary.
|
| I think the battle-ground is in part characterised by a
| schema (or service) that, once published is considered as
| immutable, hence any changes REQUIRE a NEW VERSION with a NEW
| NAMESPACE, versus a schema which allows non breaking changes
| to be introduced by both the schema owner and non schema
| authors and supports both forward and backwards compatibility.
I was thinking about relaxing the "new namespace requirement" somewhat
(without having a <xs:any> extension point). An example:
In an UBL-like approach there are different schema's for the vocabulary and
the business documents (amongst others). A vocabulary schema might have two
elements: {person-id, name}. The business documents will import the
vocabulary. Now if I want to extend my vocabulary to: {person-id, name,
birthdate}, and add some business documents which use the new elements,
there is no need for a new namespace on the vocabulary (assuming the
semantics and syntax of person-id and name haven't changed). The elements
which the old busines documents use are still in place, whether they import
the old or new vocabulary is not relevant to them. The new business
documents will need to use the new version, but there is no problem here
either if the namespace of the vocabulary is unchanged.
For business documents of course, changes will mean a new namespace.
However, one very common type of change, extension with new business
documents and business terms, is covered without requiring namespace
changes. I'm not so sure about xs:any, seems like opening Pandora's box.
| - backwards compatible yes (the previous version of a schema
| must be a valid instance of the new version), but not
| necessarily the other way around
(Typo: you mean "_an instance_ of the previous version of a schema must be a
valid instance of the new version")
I don't think it matters much in SOA. If I change a schema in a backwards
compatible way, sending v2 to a consumer which consumes v1 means trouble. If
I change in a forwards compatible way, sending v1 to a consumer which
consumes v2 means trouble. Both backward and forward compatible changes may
cause trouble, and in SOA neither sender nor receiver is a universal
preferred viewpoint. It all depends on the business case: if I send big
orders to suppliers, the sender is in charge, and receivers will make sure
they understand both v1 and v2 orders. If the sender sends big invoices, the
sender has to make sure to send whichever version the receiver understands,
or payment will be delayed. I don't really think SOA maps to the traditional
data-proces viewpoint where backward compatiblity mattered much more than
forward.
| - We have come to the conclusion that semantically the
| definition of an enumerated field is its enumerations.
| Therefore changing the enumerations changes the definition.
| Adding enumerations locally seems like a poor practice.
Not always, it depends a bit on the volatility of the enumeration. Some
examples:
a) Gender is a code list unlikely to change.
b) Country codes change, but not on a daily basis.
c) In the Netherlands postal codes are a limited enumerated set, which
changes more often than country codes, sometimes even daily.
d) In the Netherlands we also have a service which allows you (given proper
credentials) to retrieve social security numbers for citizens. The list of
social security numbers of course changes more than daily.
Cases a and maybe b can be covered by an enumeration in a schema. Case c
isn't served very well: either I must release new schemas all the time, or
add enumerations locally, which to me seems much better than having a
central authority release schemas all the time. Just let trading partners
decide when and how often they want to update their postal code schemas.
Same applies to country codes: if I only do busines with partners in the
Netherlands, Belgium and Germany, I don't really need new country code
schemas that often. If I do business worldwide, I do. Case d isn't covered
at all by enumerations. You need a web service for this. Still, social
security is not just a string of 9 integers, it is a limited set of numbers.
And thanks for the post, good overview of issues.
Marc
www.marcdegraauw.com
|
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
|
|||||||||
