[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
RE: [xml-dev] Caution using XML Schema backward- or forward-compatibility as a versioning strategy for data exchange
- From: "Michael Kay" <mike@saxonica.com>
- To: "'Stephen Green'" <stephengreenubl@gmail.com>,"'Costello, Roger L.'" <costello@mitre.org>,<xml-dev@lists.xml.org>
- Date: Thu, 27 Dec 2007 11:12:50 -0000
> e.g. because an element wasn't made optional it
> cannot be removed and so there is a temptation to change its
> semantics - to reuse it for something else rather than remove
> it.
Yes, "semantic drift" is a big problem and of course it happens even in the
absence of schema change.
Semantic drift happens naturally in the real world, for example credit card
numbers which once identified an account might start to identify a specific
card with access to that account. It's not surprising that it happens,
because if a system is capable of meeting new requirements without requiring
any software changes then people will use it creatively in new ways to meet
those requirements. One of the challenges in designing schemas (or database
integrity constraints) is knowing whether you should try to resist semantic
drift as a menace to information integrity, or whether you should allow your
system to ride the waves, thus increasing its flexibility and longevity.
System designers often underestimate the creativity of users in applying
semantic overloading to data structures. I saw one system where users were
marking certain records for review the following day, simply by entering a
particular code that was known to be invalid and would therefore appear in
tomorrow's validation report. The system designers helpfully introduced
stronger validation at data-entry time, and chaos ensued because the users
had to invent a new process.
Michael Kay
http://www.saxonica.com/
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]