RE: [ubl-dev] Code List Value Validation

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

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
>
>