[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
RE: [xml-dev] RE: Caution using XML Schema backward- or forward-compatibilityas a versioning strategy for data exchange
- From: noah_mendelsohn@us.ibm.com
- To: "Costello, Roger L." <costello@mitre.org>
- Date: Thu, 3 Jan 2008 17:55:43 -0500
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
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]