Re: [soa-rm] [Somewhat OT - "Contextual SOA"] FW: [xml-dev] Schema Extensibility

[Ken Laskey <klaskey@mitre.org>]

To me this sounds like the interacting entities have established an 
execution context and, having done the hard work once of negotiating 
policies and constraints (both business and technical), they saved 
the result and just reuse it on a regular basis.  While it can be 
looked at as point-to-point, it is reusable by anyone taking on the 
characteristics of one of the points and the saved execution context 
can be modified (versioned?) with either the original or the modified 
being used since you would identify the EC you are using.

A barely thought-out response but does it make sense?

Ken

At 02:00 PM 3/2/2006, Chiusano Joseph wrote:
>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>

--
      ---------------------------------------------------------------------------------
   /   Ken 
Laskey                                                                \
  |    MITRE Corporation, M/S H305    phone:  703-983-7934   |
  |    7515 Colshire Drive                    fax:      703-983-1379   |
   \   McLean VA 22102-7508                                              /
     ----------------------------------------------------------------------------------