RE: [ubl-dev] Re: [xml-dev] Re: [ubl-dev] UBL 2.0 and Schema Extensibility

["G. Ken Holman" <gkholman@CraneSoftwrights.com>]

(the benefit of cross posting is to get more input from others in 
other communities of users; the pain of cross posting (in addition to 
the excess number of emails) is the effort to involve those who do 
not subscribe to both into the other mail list; I won't do this for 
every post, but I have a *lot* of respect for Len's perspective on 
the real world, so I feel it important to share to this list)
====8<----

From: "Bullard, Claude L \(Len\)" <len.bullard@intergraph.com>
To: "G. Ken Holman" <gkholman@cranesoftwrights.com>,
         "XML-Dev Mailing list" <xml-dev@lists.xml.org>
Subject: RE: [xml-dev] RE: [ubl-dev] Re: [xml-dev] Re: [ubl-dev] UBL 2.0 and

They will have to understand business processes as processes and not as
one-off validations of values.   They have to understand binding order
and the proposition that bad values scale up to bad systems.  Stay out
of the realm of technical means and discuss the processes.

It depends on the audience, but the examples must be in a form they can
understand in terms of their own experience.   That is why I emphasize
reporting processes because that is a level of data aggregation that
most users are acquainted with.   A context model quickly sounds
academic if not presented by example.  A schema validation is a magical
amulet to a manager of a metal stamping shop.   An illustrated set of
forms or wizards isn't.  Do keep in mind that the extra layer isn't free
and the simplicity argument is persuasive because it is cheaper.

I don't think the problem is selling it to professional database
designers.  They know what a co-occurrence constraint is.  They know
what a data dictionary is.  These are the same people who look at XML
and say, "Where are the methods?"  We tell them, "XML is just data" and
they say, "that's not enough" and we agree.  Then we get down to means.

On the other hand, I've sat in too many meetings listening to a fine old
gentleman waxing eloquently about the benefits of XML, then starting a
discussion of rules that have to be implemented in it.   Shall we tell
him he is misinformed and misinforming?  We can't.. at least if anyone
is within earshot.  Why is he misinformed and misinforming?  His social
position.  He doesn't have to be technically astute to maintain it.  He
just has to sign checks that don't bounce.

If a programmer puts aside complexity for simplicity and the job isn't
done, they don't understand the job.  That is why superstitious
acquisition is such a dangerous problem for web technology because by
its very nature, it is an amplifier of belief right or wrong.  The
belief that the web is a 'social system' is a fine way to sell it but a
bad rubric for making architectural decisions.   It will mean that the
web becomes either inapplicable to some jobs or has external legal
layers that govern its use rather than the scalable caveat emptor
systems.   In effect, you are asking for caveat vendor, and I think you
are right.

System designers have to know that mistakes of design that cost money
cost jobs and their's is the first to go because the business goes
elsewhere when a large project fails.   When that grand old fellow makes
that speech and because of it, another company eager to get the business
wins by agreeing with him thus perpetuating the superstition, let that
business go because in a year of so, it comes back.

You have to let them fail.  They get what they pay for and if it fails,
they have to pay twice.  If one wants to win on the rebound, practice
caveat vendor design.  From the old days, "techical manuals shouldn't
kill pilots."

len