> In practice, the cost of local agreements is cheap.  Global agreements are
> not.

Much of the time this may be true, however there is also a 'tipping
point' where managing every customer contact as a unique interaction
can also be costly and consume resources that would otherwise be
available for other things (too many people standing around sticking
their fingers into holes to stop the leaks = business paralysis).

Its a bit like agile development. Cruft up some code to pass your
tests (you all practice TDD right ;-), then refactor (i.e. one aspect
of which is to remove duplication).

I'm not saying that maintaining a market sector standard is easy, or
that it won't constrain busiess operations if followed too
puritanically, but imho there *is* some utlity to be had by apriori
agreement.

Fraser.

2008/7/16 Len <cbullard@h...>:
> I'm not proposing a shared vocabulary nor advocating any is folly.  Time to
> market affects distribution in some regime of market conditions.  In others,
> the time to coalesce the agreements locally makes the most difference.  IOW,
> marketing time and community building time are not the same measurement.
> That is why systems split the document defining agreement from the document
> defining meaning.  The main difference is authority over late-bound
> composition:  design first or markup and sample then design.  In a system
> where agreements about the transactions are loose or late, the second
> technique is best, or at least, what you have to do because there is no
> shared authority, just contracting.
>
> In practice, the cost of local agreements is cheap.  Global agreements are
> not.  Traffic patterns are the best indicator of what tradeoffs to make in
> the strength of the agreement over distribution of meaning.  For some n set
> of types, a subset of n shares y percentage of subtypes.  Both y and n vary
> over time and proximity of interlocutors.
>
> Cost is best tuned locally.  Thus procurement authority over record of
> authority.
>
> It isn't a matter of sharing meaning but of authority hierarchy in the
> decision to bind/select meaning.  Second order system: not rules but who's
> rules.
>
> len
>
> -----Original Message-----
> From: Fraser Goffin [mailto:goffinf@g...]
> Sent: Wednesday, July 16, 2008 10:48 AM
> To: xml-dev@l...
> Cc: len.bullard@u...; costello@m...
> Subject: Re: [xml-dev] [Summary] Creating a single XML vocabulary that is
> appropriately customized to different sub-groups within a community
>
> Roger,
>
> I'm not sure you've covered Len's points (which could be option 5),
> although this may have been deliberate ?.
>
> That said, its not altogether clear (to me at least) what Len is
> advocating. On the one hand there is the suggestion that attempting to
> create and maintain a community vocabulary is folly and it is easier
> to allow each trading partner to define their own variant and worry
> about reconciling the differences as/when integration takes place.
>
> Whilst I have a lot of empathy with the idea that speed to market is
> often a more effective strategy that global interoperability, there
> are risks... and probably a bunch of up-stream costs that might not be
> apparent until you get there ?
>
> Len, is there any shared vocabulary in your proposal. If not, where do
> each of the participants start from, and how are shared semantics
> going to occur other than through a lot of analysis every time you
> want to connect to a new trading partner or an existing one feels like
> making a change to their local dialect ?
>
> Roger's examples were deliberately using very simple and well
> understood entities. I work in financial services and I can tell you
> that there are very few concepts that are simple or well understood !
>
> Fraser.
>
> 2008/7/11 Costello, Roger L. <costello@m...>:
>>
>> Hi Folks,
>>
>> Thank you very much for your excellent input!
>>
>> I summarized the discussions:
>>
>> http://www.xfront.com/single-xml-vocabulary-customized-for-sub-communit
>> ies/index.html
>>
>> Please let me know of any mistakes that I've made.
>>
>> /Roger
>>
>> _______________________________________________________________________
>>
>> 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
>>
>>
>
> _______________________________________________________________________
>
> 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
>
>
>