[Home] [By Thread] [By Date] [Recent Entries]
Hi Roger, I typically collapse the relationship and syntax changes into one because they come down to the same, that is they both contribute to determining whether an instance is in a version of a language. I 100% agree that a versioning strategy must cover syntax, relationships, and semantics. The W3C Technical Architecture Group has been working on this for a long time. We have been using the Accept and Defined Text Sets and the Information Set (not the XML kind) conveyed by a text of the language. The terminology section shows these terms, relationships and more. Our latest draft thoughts are: - strategies on how to achieve compatible versioning in a language: http://www.w3.org/2001/tag/doc/versioning-strategies - terminology for versioning: http://www.w3.org/2001/tag/doc/versioning - xml and xml schema designs for versioning: http://www.w3.org/2001/tag/doc/versioning-xml Your thoughts and reviews are appreciated. Cheers, Dave > -----Original Message----- > From: Costello, Roger L. [mailto:costello@m...] > Sent: Friday, December 07, 2007 12:55 PM > To: xml-dev@l... > Subject: Data versioning strategy: address > semantic, relationship, and syntactic changes? > > Hi Folks, > > Oftentimes when discussing a "versioning strategy" I focus on > how to design schemas in a fashion to lessen the impact of > changes. It occurs to me that this addresses only one aspect > of the data versioning problem. Below I have attempted to > identify other issues to be addressed in a data versioning > strategy. I am interested in hearing your thoughts on this. > > EVOLVING DATA > > Suppose some data is regularly exchanged between machines: > > Machine 1 --> data --> Machine 2 > Machine 1 <-- data <-- Machine 2 > > Periodically the data changes due to requirement changes, > additional insights, or from innovation. > > A change results in a new "version" of the data. > > > PROBLEM > > What are the categories of changes that may occur? What > categories of changes must be dealt with by a data versioning > strategy? > > > CATEGORIES OF CHANGE > > 1. Semantic - the meaning of the data changes. > > Example: > > version 1 data: a "distance" value means the distance from > the center of town. > > version 2 data: a distance value means the distance from the > town line. > > 2. Relationship - the relationship between the data changes. > > Example: > > version 1 data: there is a co-constraint between the > start-time and the end-time. > > version 2 data: there is a three-way co-constraint between > start-time, end-time, and mode-of-transportation. > > 3. Syntax - the structure of the data changes. > > Example: > > version 1 data: the employee data is listed first and the > person's name is given by his given-name and surname. > > version 2 data: the department data is listed first and in > the employee data each person's name additionally contains a > middle name. > > > SUPPORTING TECHNOLOGIES > > Suppose the data being exchanged is formatted using the XML syntax. > > Machine 1 --> XML --> Machine 2 > Machine 1 <-- XML <-- Machine 2 > > What technologies support the above categories of change? > > 1. Semantic: A data dictionary may be used to define meaning. > > 2. Relationship: Schematron may be used to express > relationships between data. > > 3. Syntax: XML Schema, Relax NG, or DTD may be used to > express the structure of the data. > > > REQUIREMENTS ON A VERSIONING STRATEGY > > A versioning strategy must take into consideration: > > - changes in the semantics of the data > - changes in the relationships of the data > - changes in the syntax of the data > > When data is in an XML format then a versioning strategy must > implement: > > - versioning a data dictionary > - versioning a Schematron schema > - versioning an XML Schema, Relax NG schema, or DTD > > > QUESTIONS > > a. Do you agree with the three categories of change? > > b. Do these categories represent all types of change? > > c. Do you agree that a versioning strategy must address > semantic, relationship, and syntactic changes? > > /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 > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] |

Cart



