OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

 


 

   Schema Extensibility

[ Lists Home | Date Index | Thread Index ]

For a while I have been continuing a thread which started out thinking about 
versioning of XML schema types, in particular enums. The debate broadened 
and a variety of helpful and interesting views were voiced about versioning 
in general and as a related subject extensibility. Personally I have been 
relating these comments to XML schema structures but I could have easily 
been talking about the service interface supported by those schema. This has 
highlighted some different opinions about the value of various approaches to 
this problem which I hope have resonated with those following the thread.

I have become quite interested in the UBL work that Ken Holman has 
introduced and the position UBL is taking about the separation of the 
validation of structural conformance versus value based.

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.

The first situation is a 'clean' and explicit model where the semantics are 
guaranteed not to be usurped by a non schema owner but where even relatively 
minor change requirements can have a large impact to implementations 
(especially when there are a large number of external users of this 
vocabulary). Changes often take a relatively long while to surface through 
into the standard and this may impact business priorities. Versioning is 
enabled through support for one or more of the available schema where, from 
time to time, old versions may be deprecated.

The schema extensibility approach promotes the idea that organisations may 
want to represent private relationships using data carried at specified 
points within the standard schema in such a way that that data is only 
relevant between those parties (using a foreign namepsace) and all others 
can safely ignore it (and that the schema author should not necessarily 
attempt to constrain this type of usage). It recognises that the pace of 
change to a standard schema often lags behind the operational requirements 
of user organisations, but those organisations don't want to throw out the 
whole standard and 'go private'. It can imply that some TP extensions may be 
incorporated back into the main body of the standard at a later point in 
which case anyone pair or parties using that extension can agree a move back 
to the standard definition, at a time of their choosing. It also allows the 
schema owner to add non breaking 'compatible' change to a schema. The down 
sides seem to be, that a TP could introduce changes which subvert the 
intended semantics, and that, over time, what might have started out as a 
temporary expedient, turns into an entrenched working implementation that is 
unlikely to be allocated budget to be re-synchronised with the standard.

So, in part the question is, should a schema allow for unknown extensions 
for unknown purposes (but in specified locations) and still be considered as 
'compliant', or should schema authors attempt to constrain (eliminate) that 
behaviour. I can't help feeling the attraction of the second model, but my 
'gut' tells me that something as inflexible will soon become a business 
constraint and that will signal it's demise.

With my SOA hat on I would recognise the importance of interoperability and 
the significant role that standardised vocabularies have to play. I also 
don't especially want to promote the myriad of point-to-point relationships 
that 'going private' implies and instead want to leverage the 'reach' of a 
market standard.

Personally I still have no definative conclusion that I feel comfortable in 
turning into a recommended approach within my own organisation and within 
the industry standards body that I work with from time to time, so I thought 
I'd give it one more go.

Some of the issues and comments highlighted by the earlier thread are 
provided below. Some are direct quotes from contributors, others are excepts 
from various ramblings :-)

Cheers

Fraser

========================

- extensibility is a critical aspect of any data [or service] model. Without 
extensibility all changes (however minor) effectively 'break' all provider 
and consumer implementations.

- there are no 'minor' changes, any change implies a semantic difference.

- 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

- xs:any together with the 'sentry' approach proposed by David Orchard (and 
others) provides a mechanism that allows XML schema to be extended by both 
the schema namespace owner and a non schema author independantly, in a 
manner which supports forwards and backwards compatibility for instance 
documents. That is, some category of change can be accomodated which do NOT 
cause either the consumer or provider implementation to REQUIRE change. Of 
course extensions added by non schema owners represent a private 
relationship between the communicating parties and therfore require an out 
of band exchange of the type definitions and semantics. Also such extensions 
can only be applied to specific locations in the base schema AND using a 
foreign namespace. This is sometimes referred to as the 'must ignore' 
pattern.

- A 'big bang' approach to versioning is not usually achievable in any 
practical sense. That is, it is generally not possible to enforce a 
'breaking' change on all users of a schema/service simultaneously (or even 
within a constrained time window).

- Support for a version of a schema/service can in some cases be self 
regulating. That is, if provider A only supports version 1.0 of a service 
whilst the majority of consumers expect to be able to integrate with version 
1.1 (or 2.0), then chances are that provider A will be unable to win any 
business and will therefore be forced to upgrade. If a consumer supports 
version 1.0 but all potential [preferred] providers have upgraded to a later 
version, the consumer may not be able to place any business on behalf of its 
customers, and will therefore be forced to upgrade (assuming that version 
1.0 and later versions are NOT backwardsly compatible).

- a schema or service interface is immutable. Once published it should never 
be changed (perhaps this is better stated as the operations which make up 
the service interface should never be changed).

- support for concurrent versions of a schema/service is more effective 
method of dealing with change than through schema extensibility. It makes 
versions explicitly typed without the ambiguity of untyped sections (xs:any) 
which require some out of band mechanism to be entered into by each 
participant. Implementing an explicit new version has the crucial advantage 
that it is guaranteed NOT to break a consumer implementation using the 
current vesion unless the provider removes that version.

- Any change to a schema represents a semantic difference and therefore 
cannot be considered as 'minor' and therefore requires a new version.

- 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.

- Adding a new value to a enumeration is not a compatible change if that 
value could be returned to a consumer who currently doesn't know about it 
(using the previous schema definition). If it's just of the receiving side, 
it MAY be compatible since the previous version remains a valid sub-set.

- schema's defined and managed by a standards body often move too slowly to 
accomodate the business priorities of particpants. Allowing local extensions 
can enable an organisation to gain advantage from the broader 'reach' of the 
base standard to the majority of its partners whilst supporting specific 
third party relationships which require additional [private] data not 
[currently] available within the base standard. Sometimes this additional 
data can represent a 'candidate' standard which may be encorporated at a 
future time.

- When standards become an inhibitor to business operations they will be 
usurped by local arrangements.

- Value based validation can be implemented as a separate layer, on top of 
structural conformance.

- Synchronisation of schema variants is necessary at the point when the 
number of variants indicates that the original semantics may have become 
obfusticated or a new semantic ecosystem [related] is emerging.

- If a large number (more than 1 :-) of buisness transactional schema 
include a common complex type, and that complex type needs to be changed, 
this can create a synchronisation problem. So is there a differnt approach 
to dealing with versioning of shared types ?

- We are undertaking a new position where the schema are going to be used 
solely for structural validation, and code list value validation (as agreed 
upon by trading partners) is a separate step.






 

News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 2001 XML.org. This site is hosted by OASIS