[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: [Somewhat OT - "Contextual SOA"] FW: [xml-dev] Schema Extensibility
Yeah, I know we've been through the "SOA and Context" thing already, but...: Forwarding an e-mail from the XML-DEV listserv yesterday - it's actually a reply by me to a question of XML schema extensibility (is a good thing, what are the dangers, etc.) that later transitioned into the SOA realm. In my reply, I brought up the notion of "Contextual SOA" - essentially SOA-based exchanges between multiple partners in which one or more require a specific "context" for their exchange that sets them apart from the others - e.g. an additional element in a message, an additional message, etc. My use of the term "Contextual SOA" here means that such "exceptions" can be handled in a robust manner, perhaps according to a (to-be-developed) standard. More below - the SOA portion is the latter portion. Surprisingly (to me at least), no one on XML-DEV contested my thoughts. Anyone here? Joe Joseph Chiusano Associate Booz Allen Hamilton 700 13th St. NW, Suite 1100 Washington, DC 20005 O: 202-508-6514 C: 202-251-0731 Visit us online@ http://www.boozallen.com -----Original Message----- From: Chiusano Joseph [mailto:chiusano_joseph@bah.com] Sent: Wednesday, March 01, 2006 8:09 AM To: Fraser Goffin; xml-dev@lists.xml.org Subject: RE: [xml-dev] Schema Extensibility > 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. I believe this is a case-by-case basis, that depends on the specific scenario(s) and business need, and - ultimately - what the level of risk regarding "unknown extensions" is, and whether or not that level of risk is acceptable for the particular case. > 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. Extensibility can also play a significant role in SOA-based scenarios (service-oriented systems). This can be handled via "contracts" between parties that specify a particular data model associated with a service, that may be different than that used by other parties that base their exchanges off the same "base" schema. Is it easy to do right now? No. I have long believed that a standard is needed for "Contextual SOA" - i.e. cases in which one or more parties that engage in a particular exchange have a special need for extensibility, and the system that handles the messages (assume SOAP messages here) for that party automatically knows to expect the additional constructs (message parts, messages, etc. - possibly further up than that in the WSDL hierarchy?) from that party and to handle them according to a specified contract involving that party. We'll get there... Joe Joseph Chiusano Associate Booz Allen Hamilton 700 13th St. NW, Suite 1100 Washington, DC 20005 O: 202-508-6514 C: 202-251-0731 Visit us online@ http://www.boozallen.com > -----Original Message----- > From: Fraser Goffin [mailto:goffinf@hotmail.com] > Sent: Wednesday, March 01, 2006 6:48 AM > To: xml-dev@lists.xml.org > Subject: [xml-dev] Schema Extensibility > > 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. > > > > ----------------------------------------------------------------- > The xml-dev list is sponsored by XML.org > <http://www.xml.org>, an initiative of OASIS > <http://www.oasis-open.org> > > The list archives are at http://lists.xml.org/archives/xml-dev/ > > To subscribe or unsubscribe from this list use the subscription > manager: <http://www.oasis-open.org/mlmanage/index.php> > ----------------------------------------------------------------- The xml-dev list is sponsored by XML.org <http://www.xml.org>, an initiative of OASIS <http://www.oasis-open.org> The list archives are at http://lists.xml.org/archives/xml-dev/ To subscribe or unsubscribe from this list use the subscription manager: <http://www.oasis-open.org/mlmanage/index.php>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]