[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [ubl-dev] Code List Value Validation
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]