RE: [ubl-dev] Code List Value Validation

["David RR Webber \(XML\)" <david@drrw.info>]

Fulton, 

I think we are violently agreeing again here!

You have introduced further considerations - how far we can push toward
that other holy grail - automatic mapping - and then my other mantra -
adaptive, fault tolerant mapping technology.

Compared to say a brittle system - such as seen in binding tools like
JAXB or XMLBeans - where any unexpected changes to the payload
structure cause catastrophic failure and a java exception to occur and
all processing stops.  There are some changes you care about - and many
more that are irrelevant to your system.  Being able to isolate yourself
by context is vital.

The strategy of being able to rapidly identify possible collision points
- do impact analysis for downstream systems - and to be able to use
registry services to publish and distribute (centralized) change
control are crucial to move beyond doing exactly what dumb EDI was
doing - but now with XML but slightly smarter but not much more
instead.

The role of the registry as the central management service is something
we've been moving towards for ten years now.  It was the original
vision in the Future of EDI - well before XML entered the picture.  The
trick is being able to link the conceptual information in the registry
to the actual runtime services.  Without that linkage - everyone
ignores the central information content after using it for the original
configuration.
 
Traditional standards organizations poorly understand this model.  The
notion that 'if only the world behaved itself and used our standards'
runs deep - and blaming problems on people not implementing the
standard correctly.  It's a Catch 22 - we need better tools that are
capable of supporting the collaborative exchange of information in a
more fluid and adaptive environment. The push to SOA is now forcing
people to address this directly. Another mantra is "transformation at
point of use".  Too often people knock themselves out trying to provide
exact formats - that their partners then mostly discard.  The classic
example is the rush to XML itself.  Someone goes to huge effort to
convert payloads to XML - and then send to partner X - who promptly
writes a mapper to convert that to EDI and feed it into their old EDI
processor.  Duh!  Know what transformation is going on at point of
use...

To be able to support transformation at point of use - you need better
ways to pass not just the data - but the rules and semantics around the
data.  So UBL is helping there - whatever the format of the data - there
is a reference point of what that content is and the constraints on it. 
But just knowing the XSD is not enough - its a start - but you need a
toolset that can provide much deeper alignment and agreement of the
actual business rules around the use and context for the information. 
And can tie in to the CPA = what the business partners are formally
agreeing is their context, roles and transaction usage.

By exposing that in a form that is machine executable and parsable - you
enable much more agile information exchanges.  You are never going to
have total magic occurring (see my p.s.) - but at least you can get
beyond really-dumb - to something more capable - and hence costs less
to maintain across a large scale marketplace...

DW

p.s. Hands-up those people storing the actual XML transactions - instead
of chopping them up into SQL tables?! 


 -------- Original Message --------
Subject: RE: [ubl-dev] Code List Value Validation
From: Fulton Wilcox <fulton.wilcox@coltsnecksolutions.com>
Date: Mon, April 10, 2006 2:27 pm
To: "'David RR Webber (XML)'" <david@drrw.info>, 'Fraser Goffin'
<goffinf@googlemail.com>
Cc: ubl-dev@lists.oasis-open.org

Payload data quality/conformance issues escalate as UBL or other OASIS
products are applied in inherently more "analog" arenas - for example,
in
healthcare. 

I do not suggest that OASIS-UBL or other Oasis groups own these data
quality
problems, but it is better to acknowledge that 1) they exist and merit
investment in more controlled vocabulary centralizers, and 2) that no
technology magic can make payload data problems go away.

                                 Regards,

                                   Fulton Wilcox

                                   Colts Neck Solutions LLC