Cart
[Home] [By Thread] [By Date] [Recent Entries]
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] |
