Lists Home |
Date Index |
- To: "G. Ken Holman" <gkholman@CraneSoftwrights.com>,"XML-Dev Mailing list" <email@example.com>
- Subject: RE: [xml-dev] RE: [ubl-dev] Re: [xml-dev] Re: [ubl-dev] UBL 2.0 and Schema Extensibility
- From: "Bullard, Claude L \(Len\)" <firstname.lastname@example.org>
- Date: Tue, 16 May 2006 09:58:12 -0500
- Thread-index: AcZ49YUluXav0/FBS4SureSTHCI+bwAAEhug
- Thread-topic: [xml-dev] RE: [ubl-dev] Re: [xml-dev] Re: [ubl-dev] UBL 2.0 and Schema Extensibility
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
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
From: G. Ken Holman [mailto:gkholman@CraneSoftwrights.com]
We have claimed it, David, and we have established it in our own
minds with illustrative proof.
It would seem that we have not established it in the community and
that is the nub of Fraser's concerns and the concerns of those on my
teleconference this morning. And I acknowledge their concerns
because they have been told that W3C Schema is the answer to
everything and many of the tools deployed were created by vendors
with the same beliefs.
And I want to allay their concerns and bring them around to
understanding there are real-world needs for working with XML that
are not satisfied using a single technology.
My concern as it came across in my call this morning was that a
programmer who puts aside the additional layers in the interest of
"simplicity" will shoehorn an inappropriate technology to solve a
subset of the problems their users will face. When users' solutions
do not work or cannot be called compliant, they will likely blame the
technology and not the insufficient implementation.
What will the community need to see to believe that W3C Schema is not
the be-all and end-all of document validation?
And I'm asking that of the community, too, not just you.