On 03/01/2008, 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.

The dates are the dates, they are fixed, it's just the interpretation
of those dates that differ, so you could just add a layer of
abstraction - call the dates date1 and date2 and let country1 treat
date1 as the IssueDate, and for country2 it would be date2.  What you
gain in "semantic interoperability" you lose in the semantic quality
of the XML.

An alternative is to add an "applicability" attribute to the elements, such as:

<issueDate applicability="X">...
<issueDate applicability="Z">...

or for more complex configuations use a child element:

<container>
  <applicability>
    <details.../>
  </applicability>
  <issueDate>...
</container>

...which is the way they do it for various plane configurations in
S1000D (iirc - it was a few years ago now that I did that).  The
processing application can then filter or ignore markup that's not
applicable to itself.  Content with no applicability attribute or
child element is applicable to all.

Huge markup efforts like S1000D and AvP70 have addressed most of these
problems, the people that designed that XML also designed the SGML
before it, and have coped with problems like versioning, multiple
variations for each country and per plane etc. so maybe learn from
their mistakes.  They have massive committees that take a long time to
change a single attribute, and clear definitions to authors about the
intended use for each bit of markup - I've lost several enjoyable
hours ensuring that a 3rd level list used roman numerals, unless it
was within a numbered paragraph, in which case it becomes a 4th level
list.

Anyway, my point is that for them the markup is the most important
thing - bigger than all of the applications that process it - so all
of the applications change when the markup changes.  A new version is
a big event.

In the vast majority of other cases, changing all of the existing
applications to accomodate a new consumer of the markup just isn't
reasonable, which leads to the slippery slope of wedging more
information into existing markup, or the new consumer just accepting
the existing markup.



cheers
-- 
Andrew Welch
http://andrewjwelch.com
Kernow: http://kernowforsaxon.sf.net/