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

RE: XML Technologies: Progress via Simplification or Complexif


progress encode

From: Bob Wyman [mailto:bob@w...]

Roger L. Costello wrote:
> Approach 1 - Progress via Simplification
> Approach 2 - Progress via Complexification
>	His note also makes reference to Wolfram's book in which
>patterns which have apparently great complexity are discovered to be the
>result of applying exceptionally simple algorithms. A common measure of
>the entropy of a system is the "number of bits" needed to encode the
>algorithm that describes the system... 

That's Kolmogorov Complexity (an idea that many have contributed to 
including Chaitin).  Wolfram is just riding a wave.

>On the other hand, if you have knowledge of the system, you'll
>use the simple, short algorithm and decide that the system has low
>entropy.

Acutually, low complexity.  Entropy is a measure of disorder and 
one should look at Fisher and Shannon information and contrast them. 
What is the uncertainty of a random set vs the uncertainty of an 
ordered set?  What is the overall length of the program?  What 
is the predictability of the output?  This has implications for 
XML design particularly with regard to frequency and occurrence. 
This has enormous implications for process specifications (think 
the orchestration and choreography languages created for web 
services).  

>Thus, apparent entropy is relative to the observer even
>though the actual entropy is independent of viewer. One measure of
>relative "understanding" or "knowledge" is the difference between
>observers in their perception of the apparent entropy of a system. 

Yes but these models are incomplete with the notion of feedback. 
It is the one notion required for evolution.  Again, if we have 
multiple observers, multiple nested processes, and multiple feedback 
loops (ports) running at different rates, what is the overall 
algorithmic complexity of the system of systems?   What can one 
do to reduce that without collapsing the system? (Think about 
the process engineering methodologies that insist on 'taking 
out work' over those that add more controls and measure more 
information.)

>	In order to arrive at minimally complex models, and thus simple
>implementations of what might have originally appeared to be complex
>systems, what we need to do is to first carefully describe and otherwise
>identify the full behavior of the modeled system. Then, when we have a
>full description of the system, we can begin to seek the usually simple
>model that describes it. 

That usually doesn't work.  In the extreme cases, you run into what 
I called in Beyond the Book, the Triple-omni problem:  it requires you 
to be omniscient, omnipotent and omnipresent.  You must know all things 
at all time and have all power over them.  This doesn't happen in reality. 
Real systems are built a piece at a time, glued together, tested, observed, 
then refactored.  The locales will vary in their discrete vs continuous 
aspects of rebuilding.   The difference in artificial and natural systems 
is the use of episodic memory.   This is why Ballard, et al insist on the 
primacy of situational controls over purely logical systems.   If you 
look at the process languages and how instances of them evolve, you 
will note that they are situational and now the issue for web services 
is determining how feedback is used to continuously or discretely 
evolve their definitions (evolution of the control over evolution 
of the product).

Once you break this down into message based systems, you arrive at the 
concepts of information ecosystems:  dynamic and directed evolution 
at very large and very small scales.

>	Ideally, in a software project, one cycles through as many
>phases of complexifiction->simplification as possible during the
>"design" phase. It is really unfortunate, although often unavoidable,
>when these phases involve released code...

No that is ideal.  The customer is an observer and has access to the 
feedback ports.  The real trick is to create an economic model that 
recognizes this without breaking the firm fixed price for the initial 
acquisition.  It's called maintenance.  The smart contract builds this 
in as services.  It is this evolution toward a services economy that 
Gertsner recognized and which has made IBM a major player while Sun 
has languished and Microsoft has worked mightily to maintain dominance 
over the core technologies.   The Microsoft hegemony will crack and 
IBM will prosper.  Sun will wise up.

But back to frequency and occurrence?  What will the effect of 
open blogging be on Sun and Microsoft?   Is the size of the 
company an issue?

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.