A fictionalization/generalization of one of the Invoice document features
might serve to make this a little more realistic:

A document type A has an IssueDate. The document was designed based
on requirements from countries X and Y where the IssueDate means the date
when the document was created. That's version 1. Along comes country Z
where IssueDate is the date when tax was applied. That is for their country
actually the only date which is meaningful on the document, they ignore the
date the document was created. Because of the political and legal situation
they insist on a new version being created which they claim is backwards
compatible but where the definition of the IssueDate is changed a little. It
is now, in version 2 a mixture of the two definitions such that all countries
are happy with it. But then along comes country Q where the document
type in question usually has both an IssueDate and a TaxPointDate and it
is the TaxPointDate which has the purpose of date when tax is applied and
the IssueDate is as it is with countries X and Y. If country Q arrives in the
design committee just before the roll-out, in the rush they persuade the
committee to add TaxPointDate to version 2. Now there is the likelihood of
a semantic interoperability problem. Does country Z start using the
TaxPointDate since it has an uncompromised definition which is exactly what
they require rather than IssueDate which has a vaguer semantic definition and
role. If they carry on using IssueDate then there is the risk it will
be misunderstood
by countries X and Y.

I practise the government of country Z (perhaps their tax authority)
realises the
problem exists and creates a subset without TaxPointDate and applies stricter
semantics - a semantic restriction - to say the IssueDate is only to be applied
to the date tax is applied. However this creates a new interoperability problem
when countries X and Y wish to send invoices to country Z.... It goes on and on.

Perhaps if the definitions were written with something like an ontology and
vague definitions were disallowed the situation wouldn't have arisen
like this...
or would that have just moved the problem elsewhere?

On 03/01/2008, bryan rasmussen <rasmussen.bryan@g...> wrote:
> On Jan 2, 2008 11:42 PM, Stephen Green <stephengreenubl@g...> wrote:
> > To elaborate:
> >
> > taking Roger's scenario:
> >
> > > [in version 1]
> >
> > > <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."
> >
>
> actually I really hated that example because I found it somewhat
> unrealistic for something that would actually happen, and somewhat
> data-apocalyptic.
>
> Cheers,
> Bryan Rasmussen
>


-- 
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