RE: [xml-dev] Will XML Schema 1.1 get traction?

["Len Bullard" <Len.Bullard@ses-i.com>]

Correct.  It's case by case which is why I say a difference that makes a
difference.  

In FpML, depending on what they are enumerating and who they are sharing
the instance with, every contract may be different, or it may be
different for a state, or even internationally.  This it seems to me
makes a good case for using the newer version of the schema to get the
constraints out of the program code and into the data specifically so
they can be versioned and cited.  In this case, they are negotiating
different deals for different customers.  Does the customer want to
accentuate provable correctness IAW with legal rules or transparency?
Or do they want to hide it (say shell game)?

If a governing or oversight authority doesn't approve (and possibly
shouldn't), then by all means make them the same.

len

-----Original Message-----
From: John Cowan [mailto:cowan@ccil.org] On Behalf Of John Cowan
Sent: Tuesday, August 14, 2012 11:02 AM
To: Len Bullard
Cc: Rick Jelliffe; Costello, Roger L.; xml-dev@lists.xml.org
Subject: Re: [xml-dev] Will XML Schema 1.1 get traction?

Len Bullard scripsit:

> The contracts officer or someone in that role type is responsible for
> that, John, and particularly in the case as Andrew suggests, where a
> separate and hopefully correctly versioned and cited code list is
used.

That's fine if you are dealing with point-to-point communication.  If
you
are a publisher, though, you have to make such decisions unilaterally,
because efficiencies of scale require that you not offer separately
negotiated contracts to each buyer (except perhaps in price, and most
of the time not even in price).

$EMPLOYER, for example, has a department concerned with the maintenance
of code lists in the range of 100 to 100,000 code elements.  Internal
negotiation is done on who's responsible for smaller code lists,
the code list department or the schema department (to which I belong).
Consequently, it's common for schemas to contain obviously extensible
but
short code lists like "book, collection, anthology, monograph, article".