XML.orgXML.org
FOCUS AREAS |XML-DEV |XML.org DAILY NEWSLINK |REGISTRY |RESOURCES |ABOUT
OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index]
RE: [xml-dev] Data versioning strategy: address semantic,relationship, and syntactic changes?

Greg, Roger, I hope you won’t mind if I give some of your interesting ideas a bit of a reality test.

 

In summary:

For us, changes are usually business driven and decided on cost, and, no, it makes little or no difference what kind of change it is.

 

In exhausting detail:

At the USPTO, our versioning strategy for the DTD’s and style sheets used for patent publications is driven almost entirely by cost.  When a change in a business process provokes a change in patent publications (about 10,000 documents per week), we look at the entire pipeline, including data source, storage, processing, validation, export to publishing contractor, publication, dissemination, consumption by internal search systems, consumption by international exchange partners, consumption by commercial value-added resellers, archives, and final disposition.  Changes to the governing DTD and style sheets are based on that entire analysis.  To the extent possible, changes are made no more frequently than annually and announced six months in advance, primarily so that everyone can get the funding in place in time, make changes, test changes, notify customers, test changes, retrain staff, test changes, update product descriptions, test changes, etc.  We like to test changes on a minimum of two or more weeks of data (20 to 40 thousand documents), but sometimes do it across many months of data through parallel runs.

 

Granted, our universe is limited in scope.  There are only about 120 patent offices in the world, only a handful use our XML data, and there are fewer than 50 value-added resellers who use our XML data that we know of.  Nevertheless, we identify all changes to everyone we know to be using the data, since we cannot predict what will or won’t break someone else’s system.  Our business is such that we cannot even dream of placing any constraints on the consumers of the data.  If we miss some of the unknown users, and a change breaks their system, we usually hear about it, especially if it tends to put them out of business.  This has happened with the most innocuous or seemingly trivial of changes as well as the more dramatic changes.  Sometimes we can fix it, sometimes not; you can imagine the rest … .

 

It has happened here more than once that some bright idea that seemed to solve a major problem received enough analysis to for us to realize that the cost of implementation far outweighed the benefit.  All our changes are “strong” in the sense of being well-specified.  If they aren’t well-specified, they become well-specified, or they don’t survive analysis and don’t get implemented.  Even the bright ideas that are ultimately abandoned have to be sufficiently well-specified to determine if they can be implemented.

 

Ontologies and such are usually indecipherable to those who don’t know the business they describe, and superfluous to those who do.  Most major business changes in the patent system occur as a result of an act of Congress or as the outcome of some litigation.  In both cases, the Office writes rules that set the meaning of terms for better or worse (and sometimes get revised accordingly), usually based on the language used by Congress or the court.  I don’t think there is any mechanical substitute for learning the business you want to engage with.  The world of commerce is far too dynamic for that.  In any case, all changes bite someone, hard or not, sooner or later, so we have little choice but to treat them all as much the same, so we don’t categorize them in any way, once agreed. 

 

During analysis, we take into account the expected benefit as compared to cost, where it can be sometimes useful to understand a change as syntactical only (very low cost as a rule), or structural (more costly, depending on the scope).  Semantic changes are always very costly in the sense of having to retrain habitual users of the data in the new interpretations required.  However, this rarely impacts the DTD (unless there are corresponding changes in structure as well) and is therefore not usually funded from the IT budget.  Nevertheless, considerations for the cost of training can stop an inexpensive DTD change.

 

There are a number of WIPO Standards that document the meaning of industrial property terminology.  These formed the basis of the vocabulary used in WIPO Standard ST.36, which the USPTO implements as Red Book.  For the most part, for a given element name, all the member states of WIPO assign the same meaning.  However, the harmony is often somewhat superficial, hiding a multitude of variations in rules, traditions, and understanding, among the member states.  That there is as much agreement as there is might be considered an achievement worthy of note.  Without that, I dare say ST.36 could not exist.

 

And yes, the intellectual property community uses those two-letter ISO country codes for a number of purposes, including place of birth, primary residence, place of filing, mailing address, agent’s address, states designated under the PCT, etc., etc.  WIPO Standard ST.3 incorporates, sometimes modifies, and even augments the list with codes for regional authorities that play the role of a patent office for more than one country.  WIPO member states frequently revisit the list as political boundaries change, since the scope of patents is generally limited to a political territory.  Countries usually enact legislation defining the changes in scope of the rights attached to a patent corresponding to the changes in political boundaries.

 

Bruce B Cox

Manager, Standards Development Division

U.S. Patent & Trademark Office

 

This email expresses my personal opinions only and should not be construed as representing official USPTO policy.

 

From: Greg Hunt [mailto:greg@firmansyah.com]
Sent: 2007 December 09, Sunday 14:47
To: xml-dev@lists.xml.org
Subject: Fwd: [xml-dev] Data versioning strategy: address semantic, relationship, and syntactic changes?

 

Roger,
I think that you need to look at some other things, semantics, structure and syntax are at too low a level because useful version management needs to be embedded in a business process or a set of business agreements. The real question is how do we identify breaking and non-breaking changes?  And then: how do we embed that identification in a change management process that minimises pain?  For simple exchanges we can nail down the purposes that people put the data to fairly easily and change management is straight-forward.  For more data exchanges involving multiple parties and multiple uses (I am thinking of some operational/statistical exchanges between Government agencies here), it is much, much harder.  The agency concerns do not overlap neatly. 

We might distinguish between strong and weak change management in this context, strong being highly specified change management and weak relying on human inspection and thought.  Most of what follows addresses strong change management. 

Change management requires constraints on users

For a versioning strategy to work there need to be constraints on the consumers (how do they extract element values, what aspects of the schema or message structure are they sensitive to), once that is done, then you can start to specify what a breaking or non-breaking change is.  For example I have seen code that simply walks through the DOM nodes of a document, extracting element values as it goes, making assumptions about the oder and types of nodes.  For that code there is no technical/structural change that is a non-breaking change because even whitespace is significant to that consumer.

On Meaning: Certain meaning is harder than "good enough", "good enough" breaks in surprising ways

Technical breakage is one thing, semantic breakage is another.  As an industry and despite a lot of people going on about semantic markup and ontologies we tend to underestimate just how fuzzy the terms that we use are.  Too many ontologies deal only with simply and sharply defined nouns, many business processes deal with things that are difficult to pin down really precisely because they are fuzzy around the edges because of either: rapid change, limited knowledge or because we simply do not care about the fine details of the definition.  An example of the not caring is the common and unthinking use of postal delivery geography from ISO 3166 as a set of country codes - Bouvet Island, permanent human population zero is a country, Scotland with its own parliament and historical identity is not?  Given that, do we really know what country codes mean?  There are other more business context specific examples: where do order prices come from? what is a bread order? what exactly is delivery?  Can you tell that I am not wild about your statement that semantics can be defined in a data dictionary?  I am not sure that we can really pin down meaning in a complete way, but we can get to "good enough" without too much difficulty.  The problem is that "good enough" must be checked and renegotiated whenever the world changes.  For example consider what happens when you try to use ISO 3166 for country of birth (I've seen it done).  Any idea how many distinct political entities there have been called Lithuania in the last 100 years?  Is East Germany the same as the Federal Republic of Germany?  What do we do with decomposition, like Yugoslavia, where there is no simple mapping between the aggregate and the current set of entities. 

Consumers use data for different purposes, defining the purposes is difficult beyond very small numbers of consumers of the data

A semantically non-breaking change for one class of consumer might present problems for another.  Consider a statistical data flow with a number of elements in it that are not summed (eg a structure containing a count of heart attacks, count of ambulance movements and a textual status report).  On the face of it, in semantic terms adding another statistical element for morbidity should not be a problem if the element can be ignored.  However, someone out there will eventually try to count instances of morbidity statistics.  If the semantics is like a set of Russian dolls, where do you stop? 

Some thoughts about semantic operations - an ontology of purposes?

If we are going to try to manage semantic change, we need to address the scope of the semantics beyond dictionary definitions.  There are operations that are based in semantics.  For example are the structures that makes up a document countable, summable or comparable inside and between instances of the document?  Countable meaning whether the number of instances of the "thing" has any meaning at all.  Summable meaning whether two instances of the element can be combined in some way, comparable meaning whether two instances of an element can be compared (comparison by name?  comparison by structure and name?).  Are two instances of an address structure comparable if they have different structure versions?  That depends on the intent of the comparer.  Addresses have a number of purposes and a change may only impact one purpose.  Adding a postal delivery point ID to a physical adress used for legal service is likely (only likely, not guaranteed) to have no effect at all on the service purpose.  If these types of operations are defined then the impact of a change can be more clearly specified.

Is an ontology of purposes possible? 

For a strong versioning strategy/change managment strategy to work, we need an ontology that is tied to the document structure so that we can minimse ambiguity.  For this element, what guarantees can we make and what operations are supported?  What operations will we  support?  If we merge a postal address and a physical address (because they are identical), are we allowed to count address elements or do we have to count the number of purposes that the elements are put to?  Is this possible at all? 

Versioning - the original question

Its not a verioning strategy that is needed.  We can attach some kind of version identifier, do stuff to make the versions identifiable and to an extent backward compatible, but the problem is the change management strategy.

Can we identify change that has an impact?  For some purposes we can, but in non-trivial cases we can never be really sure that we have captured the definition of a significant change.

Are the distinctions between the types of change significant?  I suspect that in reality they are not.  They will all bite in interesting ways.  We can minimise the amount of breaking change through various techniques, but those techniques are like those applied to object models - if you get it right it works really well, if you mistake the direction of change you have a big problem.  The XML tool sets that we have make responding to breaking change a bit easier, they are not guaranteed to make it simple and it probably should in any case not be transparent.


Greg



On 12/8/07, Costello, Roger L. < costello@mitre.org> wrote:

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@lists.xml.org
subscribe: xml-dev-subscribe@lists.xml.org
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]


News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 1993-2007 XML.org. This site is hosted by OASIS