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

RE: The subsetting has begun

  • To: "'W. E. Perry'" <wperry@f...>, XML DEV <xml-dev@l...>
  • Subject: RE: The subsetting has begun
  • From: "Bullard, Claude L (Len)" <clbullar@i...>
  • Date: Wed, 26 Feb 2003 16:27:27 -0600

RE:  The subsetting has begun
From: W. E. Perry [mailto:wperry@f...]

"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

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.