RE: Open Source XML Editor

["Bullard, Claude L (Len)" <clbullar@ingr.com>]

Don't swim in quicksand.  The flowing water and 
the action of particle against particle pull you 
under.  Float and look for a branch or yell for help. 

There is a difference between specialization of 
human skills and decentralization of organizational 
management, or specialization of roles individuals 
play and decentralization of the parts they can play.  
That difference IS competence.  We can call it an 
elite, but actually, it is pure skill and reliable, 
consistent knowledge.

Anyone out there in business taking on new XML 
projects without XML experts, and XML experts 
taking on projects without business understanding 
are all screwing each other over.  Be very clear 
because once you set these beasties, these golems 
in motion, they are very hard to stop and they 
do a lot of damage to the villagers.

We are agreeing.  Let's be sure this is understood. 
Too many people, very important people, presented 
XML, the semantic web, etc. as something that leads 
to that one button push system of Johnny fame.

Rick, Simon, others are saying, 
wait a minute, who needs agreements, we just need 
to route messages (push communication down to 
the network protocols and consider any standardization 
above that local choice).  This kind of message mapper 
might range from an organizer (inbox style) 
to a scheduler (Work breakdown structure type 
of hierarchical message routing).  I am saying, 
fine for some kinds of work but really only 
where the messages are understood a priori, the 
communication protocol is known in advance.  This 
newtwork level approach avoids the enterprise 
engineering problem the way plumbers avoid the 
family bathing schedule.  If you don't know how 
much hot water you need in advance, tough.  You 
get the forty gallon water heater because they 
have lots of those in stock.

Discoverable systems have APIs with registered 
descriptions (advertised, public) for drilling 
down into deeper descriptions.  These descriptions 
may be adjustable (terms and conditions) but the 
process is to negotiate the schedule for the route.
This is the middle ground.  We create a registry 
for services.  We describe the services so others 
can choose the description that, in their opinion, 
meets their requirements.  They engage in a 
negotiation (RFI, RFP, RFQ, BAFO, CONTRACT) 
and then watch the process to ensure the terms 
and conditions of the last piece (contract) 
are met.  This is ontological commitment and 
behavioral testing.  See XLang in BizTalk for 
one current implementation for this kind of 
system:  choose interfaces and route by schedule.

Berners-Lee says "semantic web".   Gates says 
"frictionless economy".  Sun says "the net effect". 
These are all just cheerleading terminology to 
get buy in prior to product.  A lot of energy 
gets expended but few know what the end game is. 

The choices of the tools are critical, as you 
say.  Why?  Because what you allude to is what 
the old AI crowd used to call the competence 
problem.  It is an uneven quality among the 
agents/performers/employees.  The use of generic 
tools (as Rick points out) is applied.  But how? 
I, perhaps others, prefer markup because a competent 
player can share that competence by adjusting that 
tool, tuning it to make a process tight or loose 
depending on LOCAL competence values.  Even the 
interface between two or more companies is inherently 
local.  But the CALS systems that worked well 
were sustained by the enterprise engineers.  Not 
just MIS or IT, but people with a good overview 
of the tech and the business.  If the tools they 
use, or the requirements get too complex, they 
are in quicksand.  The water is flowing, the particles 
are bumping, and they thrash until they disappear.

In CALS, we started out with a simple endgame: 
digital documentation.  We discovered as we 
tried to achieve it that certain islands of 
complex knots of process (graphic to text and back) 
made it difficult and expensive to get to the endgame.  
As we untangled each knot, we found very long strands 
of entangled types of information, some because 
the information itself was complex, and some because 
the tool strategy made it impossible to separate 
the strands, to identify them or isolate them 
from the products that wove them together.  
In still other cases, we found that the personnel 
who understood these tools had come to a point 
where they considered change unendurable or 
unsustainable.  

This was for single companies executing single 
projects with a few subs and one customer.

Now we tell the world that we can sustain a 
semantic web, a web in which we can describe 
information to sufficient detail and by such 
means as machine processing can be relied upon 
to run it while our "needy employees" do other things.
<rant>Those Microsoft commercials suck, Mr. Gates. Do 
something about your ad agency.</rant>  It may be 
sustainable; it may not be endurable.  We have to 
work that out.

We understand the use of standard document types 
and business protocols.   We understand discoverable 
interfaces and message routing.  UDDI will work 
fine and then each organization gets to choose 
the document types ((ebXML, roll-your-own)(choose one)).

But ultimately the problem of using the technology 
is the willingness of those who must choose and 
those who must use to learn the technology.  We can make the 
type definitions/schemas as tight or loose as 
they want and even if some have some points of 
view they want to enforce (as someone said, 
XML writers writing about XML), ultimately the 
customer has to choose based on their knowledge 
or lack of knowledge of their own business/art/application 
as it is affected by this technology.

That choice is the business semantic.  The elite provides 
the means to choose the means.  That's us.  We 
do that by analysing the local conditions, tuning 
the technology, and when we get into quicksand, 
get the locals to throw us a rope.

Or we disappear.

Len 
http://www.mp3.com/LenBullard

Ekam sat.h, Vipraah bahudhaa vadanti.
Daamyata. Datta. Dayadhvam.h


-----Original Message-----
From: Marcus Carr [mailto:mrc@allette.com.au]

I don't doubt that you are able to relate this to a particular organisation
or
circumstance that you have in mind, but for the life of me I can't draw a
line
between this and an operating methodology. If this can't be standardised -
that
is, if I have to be able to think like you - then the middle ground solution
relies on elites too.

I feel as though I'm swimming in quicksand.