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] RE: [ubl-dev] Re: [xml-dev] Re: [ubl-dev] UBL 2.0 and Sche

[ Lists Home | Date Index | Thread Index ]
  • 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 Schema Extensibility
  • From: "Bullard, Claude L \(Len\)" <len.bullard@intergraph.com>
  • 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
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."


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.


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

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