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

RE: The Airplane Example (was Re: StreamingXM L)

• To: 'Rick Marshall' <rjm@z...>
• Subject: RE: The Airplane Example (was Re: StreamingXM L)
• From: "Bullard, Claude L (Len)" <len.bullard@i...>
• Date: Wed, 5 Jan 2005 17:28:05 -0600
• Cc: 'Uche Ogbuji' <uche.ogbuji@f...>, xml-dev@l...

Yes.  Now we are getting into an interesting area 
of networks:  free traders and structuralists. 
Walter Perry's POV is the perfect free trader POV. 
Schemas like GJXDM represent the structuralist POV. 
Structuralists want control.   Free traders want 
opportunity.   

Free traders pass messages.  Structuralists share types.

Emergence experts stand between them beating a drum 
at some varying rate which synchonize these two 
extremes.   The difference between real time or 
simple time and enterprise time or complex time 
is the force applied to the signal that causes 
it to beat rhythmically.   It is rhythmic beat 
that makes a system predictable above the random 
value such that Markov analysis becomes useful 
and positive feedback is achieved for all agents 
in the system.   No one dances to noise for very 
long.

Beat disrupts time because mass disrupts space.
Disruption is the force of a self-annealing system. 

If chaos is the rule and simulation is the tool, 
one doesn't try to build a system that has zero defects. 
One builds a system that is robust enough to handle 
the knowns, learns from the unknowns, and recovers 
from the unknown-unknowns.   Redundancy is what we 
use to handle known unknowns.   Post-disaster analysis 
is what we use for unk-unks.  Documentation is 
everything.  Thus SGML and now XML.  

Look for sources of compatible **Data**.  Incompatible 
data can't dance. 

len


From: Rick Marshall [mailto:rjm@z...]

i really have to agree with len here. my experience in building a 
complete rdbms followed the sorts of things we have here: get ideas into 
place and working, code good, but sloppy in type checking in particular. 
lint was a pain in the neck in those days. then came standard c and an 
improved set of compilers that did static type checking properly. the 
next exercise - which took months - was to carefully investigate and 
repair all the static typing errors. there's probably more because to 
this day i haven't got all the function calls properly documented. the 
code reliability however improved dramatically! and while mixing up 
integers can be a problem, if you use strong typecasting for things (ie 
not just pointers, but typecast pointers; not just integers, but 
typecast integers) even those problems can be eliminated.

as indicated on this list dynamic or static type casting is fundamental 
to reliable software. the more the better in my view.

and one final note on static/dynamic. the former i find most useful for 
static things like compiled programs while the latter i find better for 
dynamic things like data being passed between applications.

• Follow-Ups:
  • RE: The Airplane Example (was Re: StreamingXML)
    • From: Uche Ogbuji <uche.ogbuji@f...>

• Prev by Date: Re: The Airplane Example (was Re: StreamingXM L)
• Next by Date: RE: The Airplane Example (was Re: StreamingXML)
• Previous by thread: Re: The Airplane Example (was Re: StreamingXM L)
• Next by thread: RE: The Airplane Example (was Re: StreamingXML)
• Index(es):
  • Date
  • Thread