Re: [xml-dev] [Summary] Creating a single XML vocabulary that is appropr

["Fraser Goffin" <goffinf@googlemail.com>]

> The problem is delivering a promised item six weeks before the standard is
> released to draft.   Even where one knows there is a market that needs a
> standard set of message types, timing is everything.

We are agreeing (well at least I am), and perhaps only quibbling about
the degrees of freedom available.

In the market sector that I operate in there *is* a standard
vocabulary and it is [generally] advantageous to use it (it increases
the 'reach' of a set of 'standard' transactions). That said, the
problems (and opportunities) that you are talking about *are* very
real and I recognise them. In fact, we have the similar debates
*internally* since we choose to use a cannonical message format for
our ESB.

We operate within the spirit of the standard where-ever we can. If a
choice arises between adherence, and winning a customer contract, the
contract always wins. As you say, this is usually for one of a couple
of common reasons, either the [lack of] speed with which a community
standard can be changed, or a customer who has no particular interest
in standards other than their own (we call this the 'Wall Mart'
model).

Internally we operate a messaging data model that maintains high
fidelity to the external market standard, but also allows us to
isolate ourselves from community changes, and to make proprietary
changes, as/when it suits. Just like the 'point-to-point' model, this
means we support more than one version concurrently.

Also, as well as supporting most of the market standard transactions
(and their associated data model), we offer 'private' transactions
that operate between ourselves and selected trading partners.

I think both models have their pluses and minuses, I guess thats why
we do it both ways :-)

Roger, not sure if this is helping you that much, but perhaps it gives
some pragmatic context to the problem space, although its probably my
fault that it has inevitably expanded into the 'who owns a vocabulary'
and 'who can make changes to it' extensibility and versioning
permathread.

Regards

Fraser.

2008/7/17 Len Bullard <len.bullard@uai.com>:
> There is, Fraser.  The tradeoff is doing it upfront when all one has is hope
> vs doing it later when one has requirements.  Sometimes one is advised to
> write a one-off validatible document exchange.  Sometimes one needs to write
> a message server.
>
> The problem is delivering a promised item six weeks before the standard is
> released to draft.   Even where one knows there is a market that needs a
> standard set of message types, timing is everything.
>
> Traffic analysis and use cases should precede schemas.  I don't think that
> is controversial.   I'm not sure it makes sense to start with a single
> customizable vocabulary unless the traffic analysis indicates it can be
> fielded in quick time regardless of what the use cases suggest.  IOW, don't
> take the designer's word for it.  Look very hard at the differentiation and
> rate of divergence in the subtypes first.
>
> If the traffic suggests there is a wide variation in the names for example,
> it can be best to wait for that single language and build a message server.
> The counter argument is the standard can force convergence.  The counter
> counter is no one accepts force as long as a vendor will build the one off.
> The path of least resistance overcomes globals.  So unless it really is a
> Nash equilibrium, guys say and do anything to get the girl.
>
> Outcome:  like Microsoft, you end up with VML or that early schema
> contestant and forced to support it for years, or like Sun locked in an
> internal battle for years over the costs of keeping Java proprietary.
>
> len
>
>
> From: Fraser Goffin [mailto:goffinf@googlemail.com]
> Sent: Thursday, July 17, 2008 11:05 AM
>
>> 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.
>
> This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the sender. This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail.
>