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

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

> What exactly do you mean by validation?

Hi Noah.  By "validation" I mean the use of any XML-based validation
tools, including grammar-based validation (XML Schema, RELAX NG, DTD)
and rule-based validation (Schematron).  By "processing" I mean
everything else that a client does after doing validation.

/Roger

-----Original Message-----
From: noah_mendelsohn@us.ibm.com [mailto:noah_mendelsohn@us.ibm.com] 
Sent: Thursday, January 03, 2008 5:56 PM
To: Costello, Roger L.
Cc: xml-dev@lists.xml.org
Subject: RE: [xml-dev] RE: Caution using XML Schema backward- or
forward-compatibility as a versioning strategy for data exchange

Roger:

I think this discussion would converge more quickly if you would 
rigorously define the terms in the propositions below.  What exactly do

you mean by validation, for example?  Let's say I have a purchase order

document and I:

* Use XSD to make sure a credit card number element is in the right
place 
in the document
* Use Schematron to make sure the expiration date on it is later than
the 
order date on some element far away in the same document
* Use the Java language to pull the credit card number out of the XML
DOM 
and make sure that some digits in the number properly checksum [1] the 
others (You could probably do this in SchemaTron with some work, or in 
Schema 1.1 assertions if we allowed them on simple types, but let's
assume 
just for the moment that the checksum required computation beyond what
the 
schema languages could do, or that you chose not to mess with coding
the 
LUHN algorithm in XPath.  See [2] for basic information on credit card 
number checksums.)
* Use the Java language to open a database of stolen credit card
numbers 
to ensure that the card is still "valid" and not stolen
* Use the Java language to place to the order and send a Web Services 
message to bill the card

Which of those steps do you define as "validation", and which as 
"processing"7?  Unless you quite carefully define what you mean by 
processing and what you mean by validation, then it's hard to consider
an 
assertion that:

1. Validating data is different from processing data.

Indeed, the assertion may follow from or be contradicted by the 
definitions that you choose, I would think.  Thanks!

Noah

[1] http://en.wikipedia.org/wiki/Luhn_algorithm
[2] http://en.wikipedia.org/wiki/Credit_card_number

--------------------------------------
Noah Mendelsohn 
IBM Corporation
One Rogers Street
Cambridge, MA 02142
1-617-693-4036
--------------------------------------








"Costello, Roger L." <costello@mitre.org>
12/28/2007 09:02 AM
 
        To:     <xml-dev@lists.xml.org>
        cc:     (bcc: Noah Mendelsohn/Cambridge/IBM)
        Subject:        RE: [xml-dev] RE: Caution using XML Schema 
backward- or forward-compatibility as a versioning strategy for data 
exchange


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