[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

  • From: "Stephen Green" <stephengreenubl@g...>
  • To: "noah_mendelsohn@u..." <noah_mendelsohn@u...>
  • Date: Fri, 4 Jan 2008 10:26:22 +0000

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!

Buy Stylus Studio Now

Download The World's Best XML IDE!

Accelerate XML development with our award-winning XML IDE - Download a free trial today!

Don't miss another message! Subscribe to this list today.
Email
First Name
Last Name
Company
Subscribe in XML format
RSS 2.0
Atom 0.3
 

Stylus Studio has published XML-DEV in RSS and ATOM formats, enabling users to easily subcribe to the list from their preferred news reader application.


Stylus Studio Sponsored Links are added links designed to provide related and additional information to the visitors of this website. they were not included by the author in the initial post. To view the content without the Sponsor Links please click here.

Site Map | Privacy Policy | Terms of Use | Trademarks
Free Stylus Studio XML Training:
W3C Member
Stylus Studio® and DataDirect XQuery ™are products from DataDirect Technologies, is a registered trademark of Progress Software Corporation, in the U.S. and other countries. © 2004-2013 All Rights Reserved.