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

 


Help: OASIS Mailing Lists Help | MarkMail Help

ubl-dev message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


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


>It has been difficult to illustrate to people who genuinely believe
>that W3C Schema solves all problems that there are problems for which
>it is ideally suited and there are problems for which other
>technologies are absolutely required to be used in its place.

I am *not* in this camp and neither are my immediate colleagues. Some
of the community (and to some extent the standards body I am working
with) are to a lesser or greater degree. I don't control the world and
neither do I want to. If someone wants to use 'chewing gum and string'
to build their implementation, well thats their business. If they want
to build a 'Rolls Royce' solution, thats ok too. I don't want to
constrain either extreme. Organisations have different motivations for
how they approach things and their internal politics are of no
interest to me.

Likewise with constraining anyones business model by dictating what
the data model *must* look like or how it must be processed. Again
I've heard you and others say that's *not* what UBL is attempting to
do, and partly why schema extensibility and schemaTron and NVDL et al
are of interest is precisely for that reason. That is, some aspects
are sacrosanct, but beyond these, there should be no constraint. Same
goes for the standards that apply in my sector. As soon as standards
constrain what my business guys want to do, guess what will give !

As you have said many times yourself Ken, structural validation is
sometimes a pre-requisite to other forms (e.g. schemaTron) that may be
used in addition, to cover those aspects that are not practically
possible using schema validation alone. I agree entirely.

Ultimately our message will hit the business layer and will be
accepted or rejected by that processing, so to some extent this is
pre-business process checking for whatever purpose you may determine
its necessary (saving CPU cycles or network band-width, realising that
your back end database and business process doesn't protect themselves
from a bad message damaging their integrity, supporting asynchronous
message exchanges, what-ever ....) We could argue about whether we are
doing good or bad by spreading business rules around, but lets just
accept for a moment that up-front message validation is worth-while.

So, back to my original point. It is *not* that I (or others)
necessarily think that validation by XSD alone will be sufficient, its
just that XSD *does* have a legitimate and useful role to play (even
if just limited to structural and some content validation) and I don't
want to deny that opportunity to anyone processing messages that are
specified by schema that I also subscribe too.

So, setting processContents = 'lax' as a minimum allows those that
want to perform at least some level of validation on an otherwise
opaque part of the message without the need for implementing any other
checks if they don't want to. For those that do have the inclination
to do more, they haven't lost anything and indeed as you said and now
I have repeated, the structural validation step may very well in some
cases be a required pre-step in order to remove the possibilitiy of
getting 'false positives'.

Many of the organisations that subscribe to the standards in my
industry sector are pretty small outfits with little or no IT support.
They use pre-configured packages that often provide little
sophistication for processing XML messages beyond the basics. Updating
these packages can be a costly exercise. So anything they can get 'for
free' is undoubtedly welcome.

What large organisations such as my own can acheive may well be
different (although I don't get blank checks either). But the problem
doesn't necessarily change just because of better access to resources.
As a service provider, we may feel that we want to only check the
parts of messages that are of specific interest to our business
process, but, as others have been quick to advise me in the past on
this list, claiming to implement a standard and then actually ignoring
whether or not what you receive is compliant to that standard
(including any structure which extends the standard by apriori
agreement between 2 or more trading partners), may be a slippery
slope,... semantics be damned !

Fraser.

On 16/05/06, G. Ken Holman <gkholman@cranesoftwrights.com> wrote:
> (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
>
>
> ---------------------------------------------------------------------
> This publicly archived list supports open discussion on implementing the UBL OASIS Standard. To minimize spam in the
> archives, you must subscribe before posting.
>
> [Un]Subscribe/change address: http://www.oasis-open.org/mlmanage/
> Alternately, using email: list-[un]subscribe@lists.oasis-open.org
> List archives: http://lists.oasis-open.org/archives/ubl-dev/
> Committee homepage: http://www.oasis-open.org/committees/ubl/
> List Guidelines: http://www.oasis-open.org/maillists/guidelines.php
> Join OASIS: http://www.oasis-open.org/join/
>
>


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]