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

 


Help: OASIS Mailing Lists Help | MarkMail Help

 


 

   RE: [xml-dev] The subsetting has begun

[ Lists Home | Date Index | Thread Index ]

From: W. E. Perry [mailto:wperry@fiduciary.com]

"Bullard, Claude L (Len)" wrote:

>> Walter, as much as I respect you, this is like saying all rifles should be
>> handmade:  in other words, no interchangeable parts.

>Surprisingly, perhaps, that is what I am saying. I am in the midst of writing a
>long and tiresome defense of my non-2PC, internetwork-native transaction model.
>I have been forced to realize that current distinctions between 'front office'
>and 'back office' are grounded entirely in what was automated when, and how.

Disaster Management e-Government initiative. 
"interoperability agreements must be driven
by specific needs as they are identified at the interfaces among
active participants".

I agree in general.  Ok, what about specification for interoperation 
at the interfaces where the active participants include millions 
of users and hundreds of thousands of applications?  Seems to me 
that a basic agreement they all share is a win.  For XML, that 
is the syntax first, then after that in ever smaller groups, 
the infoset.

>The assembly-line workers, the processors of batch jobs, the makers of, as you
>say, "interchangeable parts" have been discriminated against as 'not craftsmen'
>from the moment their product was no longer handmade. The current hierarchy
>supposes that they are good at production but incapable of directing it

I can understand that for many human processes, but for interfaces among 
computers, it doesn't make sense to me if applied without exception.  A 
common output model for markup systems is a pretty big win if enough people 
agree to it.

We are in the throes of a process initiative here in which the first 
decision was to divest all current stakeholders (people executing the current 
processes) of any responsibility or input to the design work or the decisions 
about changes in the processes, and more importantly, the tools we use 
to maintain them.  Here is a typical decision (I am not making this up):

"Only Vicki and I are empowered to enter new customers into the database 
because if anyone can enter them, anyone can delete them."

"Ummm... that's ok until you and Vicki are gone at the same time and 
we have some critical proposals to start on.  Couldn't you trust us?"

"No.  This is too important."

"Ok, but a better reason for what you want is the one we encounter 
most often:  different individuals starting independent work entering 
different names for the same customer.  That is better handled by 
enabling the code to search and identify similar customers and offering 
the user a list to choose from before they create a new customer."

"I can't manage that!"

"You don't have to; the code does."

"I can trust Vicki!  Who knows what the code does..."

"Right...."

"Next item.  All of these fields are now MANDATORY.  We must track 
who entered each item!"

"Ummm... there are relationships in the data that make it necessary 
to cross-check some of these entries.  If we make some of them 
mandatory, that person and only that person can update.  Is that 
what you want?"

"Absolutely!"

"Ok, again, this makes the process a bit more rigid, and in some 
cases, decisions that a person could make on their own will now 
require them to consult with three other people every time."

"Tough!  We have to make sure people are responsible."

"Ummm... they've done a pretty good job so far.  It might 
be better to go on trusting them."

"No!  I need oversight and this tool is how I will get it!"

"So you don't trust the code to help them enter customer 
names, but you are willing to incur higher costs just 
so you can make sure who did what when?"

"You aren't being a positive contributor.  I need positive 
contributors!"

Silently ... "no you want power and you are too 
insecure to trust anyone to do their job because they 
might not support you given how little you know about 
their jobs."

and so it goes... one stupid decision at a time all 
the way to insolvency.

len




 

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

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