In all of this and in the thinking behind the use of XML in general
there seems to be a hint that the schema itself has to somehow
do validation. Surely all the schema (with a small 's') or other XML
definition artifact has to do is to instruct about what validation has
to be done for compliance and what data an application is to
expect - not that the schema has to 'do' anything. I can describe
the XML any way I want - even with just prose. Then some of these
version problems seem to disappear. What bothers me is: Do they
disappear only to turn up somewhere else? And how expensive
overall is use of just prose compared to WSDL/XSD to make the
version problems go away? One would hope that if you could do
it all with just XML Schema and maybe a little Schematron and
not have to resort to anything non-machine-readable it would save
developement and maintenance costs, etc. But if that isn't actually
solving enough of the problem, eg when it comes to the next version
- meaning you have to resort to RDF/S and even some prose - then
why not use RDF/S and prose to do more, even all, of it, and give up
hope of full automation (for now).

-- 
Stephen Green

Partner
SystML, http://www.systml.co.uk
Tel: +44 (0) 117 9541606

http://www.biblegateway.com/passage/?search=matthew+22:37 .. and voice

On 03/01/2008, noah_mendelsohn@u... <noah_mendelsohn@u...> wrote:
> 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@m...>
> 12/28/2007 09:02 AM
>
>         To:     <xml-dev@l...>
>         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.
>