Re: [xml-dev] RE: Caution using XML Schema backward- or forward-c ompati

["bryan rasmussen" <rasmussen.bryan@gmail.com>]

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@gmail.com> 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@gmail.com> wrote:
> > On Jan 2, 2008 11:42 PM, Stephen Green <stephengreenubl@gmail.com> 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
>