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

Or allowing non vocabulary owner extensibility so that the
participating organisations that need a new peice of markup is not
hamstrung by a lengthy ratification process and can use that
(initially) private extension with its particular trading partners. It
may be offered back to the vocabulary owner as a candidate for the
next 'big bang'.

Some see this approach as an equally 'slippery slope' that diminishes
a community standard. Personally I don't, given that the alternative
of a standards body deciding when and if I can start using a required
piece of business data in [compatible] message exchanges provides no
great encouragement to comply to the standard and typically forces
business to 'go private' anyway. So I see the private extension
mechanism as a practical approach to slow movement. I'm not saying it
not without problems of course, but so is managing a completely
private vocabulary with each of your trading partners.

Fraser.

On 03/01/2008, Andrew Welch <andrew.j.welch@g...> wrote:
> 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/
>
> _______________________________________________________________________
>
> XML-DEV is a publicly archived, unmoderated list hosted by OASIS
> to support XML implementation and development. To minimize
> spam in the archives, you must subscribe before posting.
>
> [Un]Subscribe/change address: http://www.oasis-open.org/mlmanage/
> Or unsubscribe: xml-dev-unsubscribe@l...
> subscribe: xml-dev-subscribe@l...
> List archive: http://lists.xml.org/archives/xml-dev/
> List Guidelines: http://www.oasis-open.org/maillists/guidelines.php
>
>