Re: [xml-dev] RE: Caution using XML Schema backward- or forward-compatib

["Fraser Goffin" <goffinf@googlemail.com>]

Hi Roger,

I particularly like these 2 :-

> 6. Don't base your web service data versioning strategy on a data
> validation strategy.  Decouple your data versioning strategy from your
> data validation strategy.
>
> 7. Base your web service data versioning strategy on business needs.

however, whilst they sound fine and good, I wonder about whether, in
practice, it is quite that easy ?

When we specify a business service we might provide a WSDL, and that
WSDL might use XML schema to define the data contract for the service.

Now both of these are useful artefacts, but, as we know, they only
really describe the technical aspects of the interface, not its
semantics. That really needs to be conveyed in some other way, often
out of band.

But ... whilst we in one sense want to be unconcerned with the
implementation detail of service callers, we know that many will use
these very resources to create others artefacts by importing them into
tooling and generating part of the implementation.

So this gives us somewhat of a dichotomy; it's hard to separate out
the technical implementation details from the non technical, but the
technical artefacts are the most useful in terms of getting a working
implementation (but an implementation that does not exhibit any
technical error, isn't the same as something that implements the
business intent correctly)  !

Also, whilst WSDL and XML schema are useful to provide a reasonably
concise technical spec, WSDL and especially XML schema come with their
*own* constraints which can get *implicitly* imposed (on the
semantics). For example, as others have commented in this thread, a
content model may be defined as a sequence of information items, but
in the business context, whether one information item appears before
another may not be particularly important.

So it got me wondering about how we reconcile the needs of a service
caller in terms of providing a sufficiently concise set of artefacts
that enable them to construct their client-side implementation such
that they have a reasonable expectation that service requests will
succeed, whilst at the same time allowing the service provider to
operate different validation and processing rules than those that are
strictly part of the externally published interface.

Now that I've written this it sounds all wrong ... (sigh) .. namely
the service contract is more than just the technical interface, but I
guess thats what I'm trying to highlight here, so I'll continue. Well
actually, this does bring something up that Roger mentioned above. Is
it really the case that we will have callers of a business service who
DON'T have a clear understanding of it's purpose (semantics) ? ... and
if the semantics aren't conveyed in the technical artefacts
(WSDL/XSD), can we really have 'unknown' callers (h'mmm not sure) ??

At one level I suppose this simply means that at the service provider
end we can choose to implement validation and processing rules which
are more loose or more constrained than those assumed by the caller
based on the [technical] interface spec that they have.

and ..... since we are trying to minimise the impacts of change
(versions), we need understand whether certain changes might only
effect our internal view of the service and its data contract and
semantics, or whether the change propagates it's effects to the caller
and/or elsewhere.

All of the above is I suppose in the camp of syntactic change (ie.
visible). Semantic change is more problematic since syntax may remain
*similar* (i.e. you may introduce a new namespace thus indicating that
*all* information items potentially have a different semantic than
those in the previous namespace domain).

Sorry this is somewhat rambling. I guess a simpler way of saying it
would be ... given that most people use WSDL, XSD or both for service
implementation, should we :-

a. only consider these to apply to SYNTACTIC versioning

or .. consider that :-

b. adding/removing or changing an information item has both a
syntactic and semantic impact.

and ...

c. given (b), is it possible to separate syntax and semantic in a
practical sense.

Fraser.

On 28/12/2007, Costello, Roger L. <costello@mitre.org> wrote:
> Hi Folks,
>
> The discussion has been truly excellent.  It has clarified many
> concepts for me.  Thank you!
>
> Below is a summary of my understanding of the key concepts that have
> emerged from our discussion.  Do you agree with them?  If not, which
> ones do you not agree with?  /Roger
>
>
> RELATIONSHIP BETWEEN DATA PROCESSING, DATA VERSIONING, AND DATA
> VALIDATION
>
> 1. Validating data is different from processing data.
>
> 2. Just because an application can validate some data doesn't mean it
> can process the data.
>
> 2.1 Just because an application can process some data that it validated
> doesn't mean that *any* data it validates can be processed.
>
> 3. A backward-compatible XML Schema means that a new version of the XML
> Schema can validate instance documents conforming to an old version of
> the XML Schema.  Consider an application that is designed to process
> the old instance documents, and suppose that it has obtained the new,
> backward-compatible XML Schema.  Now it can validate both old instance
> documents as well as new instance documents.  However, just because it
> can validate the new instance documents doesn't mean it can process
> them.
>
> 4. A forward-compatible XML Schema means that an old version of the XML
> Schema can validate instance documents conforming to a new version of
> the XML Schema.  Consider an application that is designed to process
> the old instance documents.  It can validate both old instance
> documents as well as new instance documents.  However, just because it
> can validate the new instance documents doesn't mean it can process
> them.
>
> The following items are targeted at this scenario: a web service has
> unknown clients (anyone can use the service); the data it makes
> available to clients is described by an XML Schema (identified in a
> WSDL document) and some English prose (in a web page); periodically the
> data is changed (i.e. new version).  See the Amazon web service for an
> example.
>
> 5. Versioning the data made available by the web service based on
> backward- or forward-compatible XML Schemas imposes severe restrictions
> on the types of changes permitted; these restrictions may not be
> consistent with the needs of the business (the "business" is all the
> technical, political, and managerial stuff that went into funding,
> creating, deploying, and maintaining the web service).
>
> 6. Don't base your web service data versioning strategy on a data
> validation strategy.  Decouple your data versioning strategy from your
> data validation strategy.
>
> 7. Base your web service data versioning strategy on business needs.
>
>
> NOTES
>
> The assertions identify XML Schemas as the validation language, but the
> assertions apply to any validation language, such as RELAX NG, DTD, or
> Schematron.
>
> _______________________________________________________________________
>
> XML-DEV is a publicly archived, unmoderated list hosted by OASIS
> to support XML implementation and development. To minimize
> spam in the archives, you must subscribe before posting.
>
> [Un]Subscribe/change address: http://www.oasis-open.org/mlmanage/
> Or unsubscribe: xml-dev-unsubscribe@lists.xml.org
> subscribe: xml-dev-subscribe@lists.xml.org
> List archive: http://lists.xml.org/archives/xml-dev/
> List Guidelines: http://www.oasis-open.org/maillists/guidelines.php
>
>