[
Lists Home |
Date Index |
Thread Index
]
- From: "Bullard, Claude L (Len)" <clbullar@ingr.com>
- To: "Simon St.Laurent" <simonstl@simonstl.com>, XML-Dev Mailing list <xml-dev@xml.org>
- Date: Wed, 5 Jul 2000 10:22:37 -0500
I enjoyed these, Simon. A few comments:
>Not always connected If you're working on a laptop, and the application
you're working
>with uses a validating parser... you may be waiting a while. Even if you're
connected,
>network failures (like the 30,000 other users who want to retrieve the DTD
you need) may
>cause inefficiency and failure. "
Even without network failures, developers should consider:
1. Occasionally connected systems may be the rule rather than the
exception.
Even with CDPD and spread spectrum, running offline then uploading
opportunistically
is a fit design where bandwidth remains constrained. Creating usage
scenarios with
the subject matter experts and current users is advised.
2. Design to also work *off* the Internet or WWW. There are lots of
opportunities to
apply markup and related technology without using these systems.
>'Best of Breed' returns While vendors have tried to use tight
integration to bolster
>weak products with stronger ones, using an open format for connecting parts
makes it
>possible to ignore such marketing-driven connections in favor of approaches
that more
>closely resemble "the right tool for the job."
The best of breed approach looks better on paper than in an implementation.
It
is the single most expensive approach to medium to large scale systems both
in
the front end implementation and the lifecycle maintenance. I'd like to say
it
isn't true, but after seeing just how weak a DTD or schema becomes if it is
made
to service both legacy and new requirements, the details can make it almost
useless.
In effect, we end up breaking down the schemas into much smaller related
sets and use system/process constraints to determine their affective scope.
Best of breed is hard and expensive. This is a real world empirical lesson
that makes me doubt the long run efficacy of a global semantic web. I am
afraid a lot of resources will disappear down this black hole that could be
better applied elsewhere, but like all black holes, it generates a lot
of attractive energy. Some don't see the peril until they are Over
The Event Horizon and find out they are now the Wicked Witch of the East:
crushed flat by the load, shoeless and with their competitor announcing
their
demise to happy dancing munchkins and a naive development community
that now wears their shoes.
>More integration work As customers realize that they aren't stuck with
single-vendor
>solutions any more, maybe even that single-vendor solutions are no longer a
fruitful
>approach, smaller shops and development teams may get back the
opportunities that the
>large software vendors have attempted to claim.
This will vary enormously by complexity of application. Caveat emptor.
What buyers will lose when they try this will be a lot of sleep in exchange
for a
lot of responsibility both managerial and in implementation.
Again, best of breed depends tremendously not
just on shared vocabulary but shared semantics. It is incredible how
resistant
the local politic is to the global definitions. It comes down to the
calling
arguments in a function and dang, if it isn't difficult to get that to
cohere
across more than a few local processes. Standard object models help here
but getting one of these is almost the same as taking all profit out of
the product, so only the big guys can afford them, and that of course,
nails the small vendors quickly. Deep pockets help.
I say this gently but firmly: do not undersell the need to cooperate across
the boundaries of viciously competitive information ecologies. XML is
powerless without tedious human contracting processes. Of internet time
downsides, the most dangerous one is its lack of tolerance for the
tedious work required to sustain a successful process.
Len Bullard
Intergraph Public Safety
clbullar@ingr.com
http://fly.hiwaay.net/~cbullard/lensongs.ram
Ekam sat.h, Vipraah bahudhaa vadanti.
Daamyata. Datta. Dayadhvam.h
From: Simon St.Laurent [mailto:simonstl@simonstl.com]
I've just added the three presentations I gave in New York last week (1 at
the NY Object Developer's Group, 2 at XMLDevCon 2000) to my Web site. Some
of them may be interesting/useful/hateful for members of this list.
***************************************************************************
This is xml-dev, the mailing list for XML developers.
To unsubscribe, mailto:majordomo@xml.org&BODY=unsubscribe%20xml-dev
List archives are available at http://xml.org/archives/xml-dev/
***************************************************************************
|