[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

RE: [Summary] Creating a single XML vocabulary that is appropr

• From: Len Bullard <len.bullard@u...>
• To: Fraser Goffin <goffinf@g...>, xml-dev@l...
• Date: Thu, 17 Jul 2008 13:01:30 -0500

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@g...] 
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.

• Follow-Ups:
  • Re: [Summary] Creating a single XML vocabulary that is appropriately customized to different sub-groups within a community
    • From: "Fraser Goffin" <goffinf@g...>