[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: Caution using XML Schema backward- or forward-compatibilit
Well, I think changing the semantics of elements falls outside the normal understanding of compatibility. Cheers, Bryan Rasmussen On Dec 26, 2007 8:01 PM, Costello, Roger L. <costello@m...> wrote: > > > Thanks Derek. Yes, you are correct, my comments apply not only to XML > Schema, but also to Relax NG and DTD (i.e. to any grammar-based schema > language). > > Moments ago I saw the following message. It summarizes perfectly the > point I am trying to make. > > Someone wrote: > > > If an application is implemented to understand a v2 schema, it is > > considered backward compatible if it can successfully process XML > > documents that are created from either the v2 schema or from the v1 > schema > > I responded: > > Not true. The application *may* be able to process v1 XML documents. > The only thing that a backward compatible schema guarantees is that it > can *validate* v1 XML documents. Backward-compatibility in no way > guarantees that applications can *process* v1 XML documents. > > /Roger > > > -----Original Message----- > From: derek denny-brown [mailto:zuligag@g...] > Sent: Wednesday, December 26, 2007 12:30 PM > To: Costello, Roger L. > Cc: xml-dev@l... > Subject: Re: Caution using XML Schema backward- or > forward-compatibility as a versioning strategy for data exchange > > Your title and summary indicate that you believe that these > limitations are specific to XML Schema, but nothing I saw in your > examples ties the issues you highlight to XML Schema. Fundamentally, > creating a forward compatible schema amounts to attempting to predict > the future. Other schema languages for XML may provide stronger > capabilities, but ultimately you face the same problem. > > XML is a means of communicating information. Handling versioning of > information exchange is a problem that has been with us as long as > humans have had communication. Computers and automated processing > exacerbate the problem because of their lack of flexibility. A > teenager can adjust to the language of Herman Melville, but skip a > single semicolon and your C compiler falls on the floor. Versioning > schema for XML is not significantly different than versioning a code > library's API. Both require careful thought and understanding of the > customers, scenarios, and tradeoffs. Both eventually require breaking > changes, and even a complete rewrite to cleanly incorporate certain > changes. > > XML Schema is just one way to express constraints on what kind of XML > is deemed correct. Throw away XML Schema and imagine near-infinite > freedom to define the rules that validate an instance. As bad as XML > Schema (1.0) is at handling versioning, I argue that you will find > still find the same core versioning issues. > > -derek > > > On Dec 26, 2007 8:09 AM, Costello, Roger L. <costello@m...> wrote: > > Hi Folks, > > > > Designing XML Schemas to be backward- or forward-compatible is a > > popular approach to data versioning. > > > > I think some cautions need to be raised with versioning strategies > > based on XML Schema backward- or forward-compatibility. > > > > Below I list the cautions. Do you agree with these cautions? Are > > there cautions I have missed? > > > > > > SCENARIO > > > > Consider deploying a web service. Assume the web service has no > > knowledge of who its clients are, or how clients use the data they > > retrieve from the web service. > > > > The web service uses an XML Schema to describe the syntax of the data > > it exchanges with clients. > > > > The web service uses the following data versioning strategy: > > > > Each new version of the XML Schema is designed to be > > forward-compatible. > > > > Thus a client with an old XML Schema can validate an XML instance > > document generated by the web service using a new XML Schema. > > > > > > ISSUE > > > > Given the scenario described, what cautions should be raised on the > use > > of forward-compatible XML Schemas as a versioning strategy for data > > exchange?" > > > > > > NOTE > > > > A versioning strategy based on backward-compatibility has the same > > cautions. I will not explicitly mention backward-compatibility in the > > rest of this message, but bear in mind that the comments apply to it > as > > well. > > > > > > CAUTION #1: JUST BECAUSE A CLIENT CAN VALIDATE THE DATA IT RETRIEVES > > DOESN'T MEAN IT CAN PROCESS THE DATA > > > > Consider a client application implemented to process version 1 data > > from the web service. > > > > Suppose the web service changes its XML Schema, in a > forward-compatible > > fashion. Will the client application be able to process the new > > (version 2) data? > > > > Since the XML Schema is forward-compatible the application will be > able > > to "validate" the new data. > > > > But it is not necessarily the case that the application will be able > to > > "process" the new data. > > > > Example #1: Suppose in the first version of the XML Schema this > > element: > > > > <distance>100</distance> > > > > means "distance from center of town." Accordingly, the client's > > application does calculations based on that meaning. > > > > In the version 2 data the syntax is changed in a forward-compatible > > fashion. In addition, the semantics of the <distance> element is > > changed to "distance from town line." > > > > The client application will be able to validate the version 2 data, > but > > the calculations will be incorrect. > > > > Example #2: If the version 1 XML Schema defaults the <distance> units > > to miles and the version 2 XML Schema defaults the <distance> units > to > > kilometers then the data will validate but the client's application > > will make incorrect calculations. > > > > Lesson Learned #1: Data may change syntactically in such a way that > > validation is not impacted, and yet applications break. > > > > Lesson Learned #2: Just because an application can validate data > > doesn't mean it can process the data. > > > > Lesson Learned #3: Forward-compatible XML Schemas yield increased > > validation but not necessarily increased application processing. > > > > Lesson Learned #4: There is no necessary correlation between the > > ability to validate data and the ability to process data. > > > > Lesson Learned #5: A versioning strategy must take into account: > > > > 1. Syntactic changes > > 2. Relationship changes > > 3. Semantic changes > > > > > > CAUTION #2: FORWARD-COMPATIBLE CHANGES ARE BASED ON TECHNOLOGY > > LIMITATIONS RATHER THAN APPLICATION REQUIREMENTS > > > > Designing a new version of an XML Schema to be forward-compatible > with > > an old version necessitates that the only changes made in the new > > version are "subset" changes, such as: > > > > - constrain an element's or attribute's datatype > > - reduce the number of occurrences of an element > > - eliminate an optional element or attribute > > - remove an element from a choice > > > > This is very restrictive. And to what avail? Answer: to enable > > validation of new XML instance documents against an old XML Schema. > > But as described above, just because data can be validated doesn't > mean > > it can be processed. > > > > Further, for the scenario we have been considering, the web service > has > > no idea about how its data will be processed by clients. > Accordingly, > > there is no evidence that the additional validation provided by > > forward-compatible XML Schemas will help clients. > > > > Lesson Learned #6: A versioning strategy based on forward-compatible > > XML Schemas imposes limitations on the types of changes; those > > limitations may not be consistent with the actual changes needed by > an > > application. > > > > Lesson Learned #7: Version data based on data requirements rather > than > > technology limitations. > > > > > > QUESTIONS > > > > 1. Do you agree with the cautions listed above? > > > > 2. Are there other cautions? > > > > 3. Do you agree with the Lessons Learned? > > > > 4. Given the scenario described above, is it wise to base a > versioning > > strategy on forward-compatible XML Schemas? > > > > /Roger > > > > > > > _______________________________________________________________________ > > > > 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@l... > > subscribe: xml-dev-subscribe@l... > > List archive: http://lists.xml.org/archives/xml-dev/ > > List Guidelines: http://www.oasis-open.org/maillists/guidelines.php > > > > > > _______________________________________________________________________ > > 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@l... > subscribe: xml-dev-subscribe@l... > 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] |
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
|