[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: RE: Caution using XML Schema backward- or forward-compatib
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: 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. >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] |
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|