[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: RE: Caution using XML Schema backward- or forward-c ompati
Yeah, but IIRC the UBL NDR mandates backward semantic compatibility - I don't think actually that the change wanted by country Z should be accepted as matching that requirement, although as you point out there is the risk because there is a disconnect between the ability of committees to match technical requirements for their work with 100% perfection. Note on that: I don't think anything was ever specified about being able to invalidate and roll-back a new version of a standard if the standard can be shown to not match the requirements on the standard, that would certainly be an interesting experiment in destroying the world and for that reason I approve it, but in practice to validate that a standard conforms to the technical limitations placed on its development is all on the front end. The only acceptance testing of standards seems to be do people use it or not. Unfortunate, so I agree the scenario you describe below CAN happen, I disagree however that it follows the rules for what SHOULD happen in the context of UBL. Is there something at the top organizational level of OASIS or other standards organizations that allow the publication of a retraction of a standard and mandate a moveback to a previous standard for an indeterminate time? I hope the above makes sense, I think this is one of those subjects that is somewhat vague and as a consequence the attempt to develop a nuanced understanding of it in some ways contributes to e ever increasing vagueness. Or maybe I am thinking poorly, not having had my double espresso yet. Cheers, Bryan Rasmussen On Jan 3, 2008 10:35 AM, Stephen Green <stephengreenubl@g...> wrote: > 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] |
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|