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