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

["Costello, Roger L." <costello@mitre.org>]

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.