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

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

As Dave suggeste, it is likely that (in a B2B scenario particularly
where the data model is centrally governed for a trading community)
you will only be interested in a subset of the data that actually is
received (that required for business processing).

One approach to this is to create your own validation artefacts
(schema, schematron, Java code, whatever ...) that only operate on the
data set of interest.

Equally you *may* tranform the inbound data into something that
complies to your internal data model, effectively 'filtering out'
potentially incompatible changes which you don't care about.

This approach suggests using an internal data model which is
compatible with the external (has sufficient fidelity for
transformation between the two), but is somewhat more decoupled from
the impacts of some changes in the external. Your internal versioning
strategy may thus differ from the external.

Thus when a change occurs in the external [service interface] this may
not effect your internal view at all.

Of course when a message crosses the boundary between external and
internal, for the request or response, it must meet the demands of the
direction in which it is going.

In many cases this means that data of no interest that has been
received can't always be discarded (ie. the 'filter' above doesn't
mean throw the data away, it means, don't pass it to this piece of
processing). This is particularly so, when
data received is required as part of a response. So regardless of
whether we view it as important internally, the [external] service
contract specifies that the client should expect that data. There
might also be audit or legal reasons why we can't
just throw data away that has been received (e.g. non repudiation).

It may be possible to view this more generally (to cover internal
applications calling internal services) by, instead of saying
external/internal, use origin data format/receiving data format ?

Fraser.

On 03/01/2008, Dave Orchard <orchard@pacificspirit.com> wrote:
> I don't know quite what you mean by "match", which is I think the core of any attempt to define semantic interoperability.  It would
> be really nice if we could define an information model for Version 1 (I1), then an information model for Version 2 (I2), and have a
> language-agnostic mechanism for doing a mathematical test to determine whether I1 is compatible with I2.  My thinking is that there
> isn't such a mechanism because the domain of I1 and I2 are infinitely complicated and innumberable, whereas the syntax of any given
> language is finite and so syntactic compatibility can be mechanically determined.
>
> One approach that was suggested was that the best one can do in general is to say that a I1 is compatible with I2 if I1 is
> sufficient to generate a subset of I2.  In the example given of the distance changing, then <distance> changing without the
> reference attribute is incompatible because I1 can't be used as-is to generate something in I2.
>
> Now you've also given an example of using 2 different schema languages that express different allowable instances.  Said
> differently, there are 2 different schema languages used that express different Accept Sets.  Your use of the client's RelaxNG
> having a larger Accept Set than service's Schema is effectively a reproduction of Postel's law, be strict in what you produce and
> lax in what you accept.  Typically the service will tell the client what it will be producing, and in this case it would be a
> schema.  In many cases, the client will then use that definition for what it expects so the client and service schema are usually in
> lock step, though not necessarily.  And of course, the reverse problem holds, which is that if the client ever wants to send
> distance units, it needs to make sure that the <distance>s it sends are compatible with the services, which may not hold if the
> allowable <distance>s from the client are a super set of the service's Accept Set.  Another advantage of using the same definition
> for both...
>
> I think there is a lot of benefit in using partial understanding for increasing compatibility.  If the client can use only part of
> the data, then the service can easily change the rest of the data in a compatible way.  But if the client validates all the data,
> even the data that it doesn't use, then that usually restricts the kind of changes that a service can make in a compatible way.
>
> Cheers,
> Dave
>
> > -----Original Message-----
> > From: Costello, Roger L. [mailto:costello@mitre.org]
> > Sent: Thursday, January 03, 2008 9:37 AM
> > To: xml-dev@lists.xml.org
> > Subject: RE: [xml-dev] RE: Caution using XML Schema backward-
> > or forward-c ompatibility as a versioning strategy for data exchange
> >
> >
> > Hi Folks,
> >
> > On the issue of interoperability ...
> >
> > I think that interoperability must be defined for a specific context.
> > Below is an example context, followed by a definition of
> > interoperability for that context.
> >
> > [Note: most, if not all, of the below has been stated in
> > earlier messages, so this is primarily just a summary;
> > hopefully a useful one.]
> >
> >
> > CONTEXT
> >
> > A web service is deployed, from which clients fetch data.
> > The web service has no knowledge of who the clients are, or
> > what they do with the data.
> >
> >
> > DEFINITION OF INTEROPERABILITY
> >
> > Suppose a client fetches data from the web service.  There is
> > interoperability when:
> >
> > - the data's syntax and relationships fulfils the client's
> > expectations
> > - the client's expectations on the semantics of the data
> > match the web service's intended semantics
> >
> >
> > TECHNOLOGIES THAT FACILITATE INTEROPERABILITY
> >
> > There are some technologies that can be used by a client to
> > determine whether the data's syntax and relationships fulfill
> > his expectations:
> >
> > - Grammar-based Schema Validation: by validating the data
> > against a grammar-based schema a client can determine whether
> > the data is syntactically what he expects.
> >
> > - Schematron Validation: by validating the data against a
> > Schematron schema a client can determine that the data
> > relationships are what he expects.
> >
> >
> > WHERE INTEROPERABILITY STUMBLES
> >
> > There is no technology that enables a client to determine
> > that the meaning he expects the data to have matches the
> > meaning the web service intended the data to have.
> >
> > For example, consider this data:
> >
> >     <distance>100</distance>
> >
> > Suppose the client expects the data to mean "distance from town line,"
> > but the web service intended it to mean "distance from town center."
> > The data is not what the client expects, but he has no
> > automated way of detecting this.
> >
> >
> > MINIMIZING INTEROPERABILITY GAPS
> >
> > Clearer definitions will help reduce gaps. Additional
> > metadata may also help.  For example, we may minimize the
> > risk of misunderstanding the <distance> with additional metadata:
> >
> >     <distance units="meters" reference="from town
> > center">100</distance>
> >
> > However, even here there is room for misunderstanding, e.g.
> > what is the meaning of "town center?"
> >
> > So the gap can be reduced but never eliminated.
> >
> >
> > IMPLICATIONS ON DATA VERSIONING
> >
> > The schemas used by the clients and web service don't have to match.
> > As long as the data meets the client's expectations, that is
> > all that matters.
> >
> > For example, suppose the web service declares the <distance>
> > element using this XML Schema:
> >
> >     <element name="distance">
> >         <complexType>
> >             <simpleContent>
> >                 <extension base="byte">
> >                     <attribute name="units" fixed="miles"/>
> >                 </extension>
> >             </simpleContent>
> >         </complexType>
> >     </element>
> >
> > Here is an XML instance that conforms to the XML Schema:
> >
> >     <distance>100</distance>
> >
> > A client fetches the XML instance from the web service and
> > validates it against his schema:
> >
> >     <element name="distance">
> >         <data type="integer"/>
> >     </element>
> >
> > Notice that the client uses a RELAX NG schema to validate the data.
> > Further, the schema doesn't specify a fixed attribute, and it
> > uses a less constrained datatype.
> >
> > That's okay. The XML instance meets that client's
> > expectations and that's all that matters.
> >
> > The web service can version its schemas as frequently as
> > desired.  As long as the syntax of the XML instance documents
> > is unaffected, the client's expectations are fulfilled and
> > there is interoperability.
> > However, any syntax changes, even minor, may break the
> > expectations of some clients.
> >
> > Thoughts?
> >
> > /Roger
> >
> > P.S. I believe this idea of "expectations" is what Walter
> > Perry has promoted for many years.
> >
> >
> > ______________________________________________________________
> > _________
> >
> > 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
> >
> >
>
>
>
> _______________________________________________________________________
>
> 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
>
>