OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help



   Re: Babel (again) or standard taqs and aliases (UDEF, Bizcodes)

[ Lists Home | Date Index | Thread Index ]
  • From: Len Bullard <cbullard@hiwaay.net>
  • To: ebohlman@netcom.com
  • Date: Mon, 01 May 2000 20:46:47 -0500

Eric Bohlman wrote:
> In closing, technology often *does* drive social change all by itself, but
> rarely in a predictable direction.  Planned attempts to drive specific
> social changes by purely technological means rarely succeed.

The difference is the feedback control loop.  Social changes will occur 
and some are predictable based on the results of shaping of the

Sweeping changes of the kind heralded by the WWW are rarely what they 
want them to be.  In my experience, it is more likely they get exactly 
the opposite:  more information -> more nonsense.  A FreeNet -> more 
intermediaries to filter spam.  A free Internet -> an Internet dominated 
by click throughs and the collection of personal information.  A great 
equalizer? How much free will can you afford?
The schema declares an environment and the wrapper systems such as SOAP 
provide a means to chain the S/R events.  Chaining occurs when the
for the result is the next stimulus, thus operant conditioning in an 
S/R chain.  The results become very predictable at some threshhold.  
The behavioral engineer, the information engineer, both design such 
chains based on local rules for rewards to shape a behavior to 
emergence or extinction.

Choose wisely but understand that free will is limited.  Once you 
make a contract, you honor it; otherwise, tit for tat, and you lose 
in the next cycle.  Lifecycle is determined by the shaping of local 
behavior by environment an environment by local behavior.

The problem is superstitious acquisition of behaviors.  Don't look for:

1.  BigGuy vs LittleGuy:  the historical speculation that TEI produced 
what CALS didn't is rubbish.  CALS rewarded a specific set of designs 
and by and large, paid the bills for the industry you now have.  TEI 
was an academic hobby.  Both produced results, but only one produced a 
large and substantially endowed ecology. 

2.  Conspiratorial emergence:  you don't need that, you don't need to 
impute motivation.  Behavior is sufficient where that behavior is 
observable and predictable.  Observe and test.

3.  Conspiratorial failure:  Initiatives usually fail when they 
do not originate in the community of interest.  The interests of OASIS 
are not the interests of the auto community.  It is that simple.  
Where OASIS assists those who have not yet become competent with 
markup technologies to become competent, they will be welcomed. 
If they go where the expertise already exists, they will be 
viewed with suspicion and rightfully so.  Choose wisely.

The WWW experience has left many with a mythical view of how 
communities arise.  Drop the hero stuff, drop the New Economy stuff, 
and understand the system.  It is an amplifier.  It enables things 
to go faster but not necessarily with better quality.  A community 
of trading relationships works the same in any language of exchange. 
The web is plumbing and storage.  Virtual assets are tied to physical 
assets.  Systems in which only important people are endowed with 
rewards still depend on disenfranchisement.  

Ford refuses to be disenfranchised.  They know that local behaviors 
are shaped by the environment and that one of the local behaviors 
is to shape the environment.  So they seize their own destiny and 
make their own standards.  That IS what markup is to enable.

Understand the zeitgeist.  What once was old may be new again 
and be very successful.  HushPuppy shoes?  Markup?

If UDEF is adopted with military codes, que bueno.  The military 
likes such frameworks, has historically used them well, and will 
adapt them as needed.  Other communities who do business with 
them will, by DID and CDRL do the same.  How much they expose 
their inner processes and data to inspection is a matter of contract.

SOAP is neat, BTW.  Well thought out and serviceable.


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/


News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 2001 XML.org. This site is hosted by OASIS