[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [ubl-dev] Code List Value Validation
Dave,
Dave,
I agree with respect to there being a practical need for balance between
content standards force fit versus agility.
On the other hand, the notion that a controlled vocabulary makes jobs for
the controllers and centralizers is probably misplaced, because we need more
and probably better funded such efforts. These code sets force fit
real-world, often "analog" information into a form suitable for consumption
by very stupid machines.
The codelists we are discussing, such as country, currency, etc. involve
"payload" data. Such payload data needs to survive UBL encapsulation and
de-encapsulation in a fashion that aligns the behavior and content of the
recipient's and the sender's internal systems. If that synchronization
process experiences exceptions, there goes the ROI of UBL.
Progressing from "classic" EDI to XML (in any flavor or setting) does not
reduce the cost of quality involved in supporting hands-off machine to
machine exchanges. In the end, data "non-conformance to spec" requires that
people do "mapping," transaction recovery/troubleshooting, and perhaps
custom software or scripting development.
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
-----Original Message-----
From: David RR Webber (XML) [mailto:david@drrw.info]
Sent: Monday, April 10, 2006 9:20 AM
To: Fraser Goffin
Cc: ubl-dev@lists.oasis-open.org; fulton.wilcox@coltsnecksolutions.com
Subject: RE: [ubl-dev] Code List Value Validation
Fulton / Fraser,
While it seems a little off topic philosophy is so important here.
What makes a standard? Context, applicability, predictablity and
convenience to me are key drivers in adoption.
But the EDI has past and now XML world present will continue to struggle
with this because of on the one hand there is a natural wish of control
and centralization - to make everyones lives easier by edict - (and to
also frankly justify the existence of the central authority?!?).
This misses the fact that standards are never static they evolve. Two
examples that seem should be invarient prove the point - currencies and
countries. Who thinks these ever change? Actually turns out they do.
Then you move to the extreme - like technology - trying to come up with
a definition for components in a laptop for example - changes every 3 to
6 months.
Commerce is all about evolving markets and being able to adapt rapidly
to gain or keep advantage. (Even the French are now having to change
how they make and market wine!)
Therefore you need a codelist system that is at once predefined and
immutable - and the other hand able to accept change and promote and
clarify change. Exposing change based on context. This is what we
have learned from the original ebXML v1 work - how to leverage context
mechanisms - and build those into our XML technologies.
That is what IMHO the work on CAM is all about. It's a contradiction.
On the one hand you want tools that promote the use of systems like UBL
that seek to reduce the permutations and align around common
vocabularies - but on the other hand you want built-in flexibility so
that people can quickly and easily see the deltas between the
perscribed and the actual.
This can be very subtle - example XSD - I argued and lost with the W3C -
that min / maxOccurs mechanism conceals context instead of exposing it.
Because every single element has a min / maxOccurs - its now impossible
to know where the exceptional is - seeing the wood for the trees.
Conversely in CAM the default is always mandatory / one, or simply
repeat (any) - hence I can query a CAM template for any occurance of
LIMIT - and instantly find out if my trading partner is using a context
driven change to the norm that my systems need special handling for
(e.g. LIMIT 20 - so they only accept 20 line items - not ANY). (BTW -
XSD *, 0 - 999 etc not the same - since - yes - the perscribed way of
using these is too variable - not predictable!)
Similarly the codelists need the same techniques. Where you can quickly
use the default list - but when you need flexiblity - such as new
products coming to market - you can adapt and notify your trading
partners exactly what are the deltas.
A standard is only as useful as its applicability to the real world -
and hence we need a blend of approaches here. The ability to perscribe
and the ability to adapt in a predictable way.
This is the paradox that UBL needs to embrace.
DW
-------- Original Message --------
On 08/04/06, Fulton Wilcox <fulton.wilcox@coltsnecksolutions.com> wrote:
> In accommodating the need for "non-standardization", I suggest that there
> are two conditions to avoid.
>
> 1. Avoid helping people make "stealth" exceptions, in which everything in
> the UBL transaction looks "standard," even though it is not.
>
> As a hypothetical example, someone who trades within the U.S. and who has
an
> organizational focus on the New England states of the U.S., might decide
to
> invent and use NE as a country code. This example is weird, but I've seen
> weirder.
>
> Stealth implementation of this sort of exception is a problem, because
even
> though "trading partners" agree and understand what they are doing, those
> "partners" often are far removed from the broader interests of their own
> companies, let alone third party interests - the tax people, the 3rd party
> logistics provider, etc.
>
> 2. Avoid the "crowding out" of standard data by non-standard data.
>
> If trading parties can easily stuff non-standard data where the spec calls
> for standard list entries, that preempts the inclusion of available
standard
> data. If as shown in my example the person wants to include "NE"
somewhere,
> what UBL offers to facilitate that inclusion should not preempt the use of
> the actual country code.
>
> At some point, a standards group has to say "this far and no further." I
am
> not sure that what is being proposed in fact creates either stealth
> situations or crowding out, so I offer these as operating principles
rather
> that specific feedback.
>
> Note that I am not indifferent to the need to sometimes violate standards.
> In the interest of doing business with some very distinguished global
> companies with some very undistinguished data practices, I personally have
> had to contribute to the art of "misuse of standard transactions." On the
> other hand, what is situationally necessary should not inadvertently be
> blessed as a valid part of the standard.
>
> Regards,
>
> Fulton Wilcox
> Colts Neck Solutions LLC
>
>
---------------------------------------------------------------------
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]