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

RE: The Best Technologies Don't Win


gjxdm
It isn't so much that the best technologies don't win, it is that they
don't matter in an evolutionary game of selection.  Remember, this isn't
a Darwinian model; it is a model of evolutionary stable strategy and in
that game, all that is required is that the dominating genetic base/rule
set/schema/architecture (pick one) cannot be replaced by a minority or
invader set.   (This is a model that is more robust than a Nash
equilbrium because it doesn't rely on rational players.)

1. To dispute Rick Jeliffe a bit: there are applications that use the
exotic non-overlapping functionalities of XSD.  The one that comes to
mind in the markets I see is GJXDM.  Why?  It needs a data dictionary
that is customized, not a single schema for one XML application.  Why?
It must map to multiple overlapping local jurisdictions because the
Federal government does not have the power to mandate local system
reporting requirements except insofar as these report up the chain
through the State switches to Federal databases, and insofar as grant
money is predicated on conformance to Federal standards.  These are very
loose functional relationships.   I suspect that for many multi-million
dollar buys, this is true.  When building a web site, the functional
relationships that dominate the requirements are different, but they
require many sales.  The scaling qualities are quite different.

2.  When picking among the alternatives, requirements dominate clever
code.  A very real challenge to cat herding is knowing which cats are
doing something useful, say, can be sold in a contracting environment if
you sell big systems.

If the RFPs require an SOA that uses GJXDM-derived Reference Models to
derive local schemas (the problem is not XML or REST; the problem is
local jurisdictional choice over Federal models), then attempting to
apply REST/RELAX means losing the contract, not the technology.  If one
bids 'strong-objects with data entities', one loses.  It doesn't matter
that the code is clever; it matters that it doesn't map to the
requirements AS WRITTEN.

Web architecture isn't as important to big sales as selling applications
that use the Internet and a message switch.  If you take the path of
architecture and open source, you have to map it to the requirements in
the customer's solicitation.  Otherwise, you end up with $4 a share
stock (see Sun) because you lose too many big sales.  The evolutionary
game is won in the Proposal response to the Request for Proposal, not
the coding shop.

Sad but so.  The low cost transport model uses the bidding process, not
the design process.  One can feed the other but that is very slow and
the trade IS time for energy.  Until you shape the customer's
preferences, you lose.

Note carefully the function of abstract types over derived types.  That
is the requirement for GJXDM and any other schema that has to map into
multiple local customizations.

len

PURCHASE STYLUS STUDIO ONLINE TODAY!

Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!

Buy Stylus Studio Now

Download The World's Best XML IDE!

Accelerate XML development with our award-winning XML IDE - Download a free trial today!

Don't miss another message! Subscribe to this list today.
Email
First Name
Last Name
Company
Subscribe in XML format
RSS 2.0
Atom 0.3
 

Stylus Studio has published XML-DEV in RSS and ATOM formats, enabling users to easily subcribe to the list from their preferred news reader application.


Stylus Studio Sponsored Links are added links designed to provide related and additional information to the visitors of this website. they were not included by the author in the initial post. To view the content without the Sponsor Links please click here.

Site Map | Privacy Policy | Terms of Use | Trademarks
Free Stylus Studio XML Training:
W3C Member
Stylus Studio® and DataDirect XQuery ™are products from DataDirect Technologies, is a registered trademark of Progress Software Corporation, in the U.S. and other countries. © 2004-2013 All Rights Reserved.