[
Lists Home |
Date Index |
Thread Index
]
> 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>
>
|
