[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: SV: SV: [ubl-dev] UBL Basics.. try "Productivity"....
Bryan, I'm on the pragmatic practice v theory train today. Fact and theory - Wikiquote "In theory, there is no difference between theory and practice. But, in practice, there is." ~ Jan L. A. van de Snepscheut... en.wikiquote.org/wiki/Theory In theory the CAM work has been focused on providing the bridge - the better mouse trap here - that allows you to use a broad variety of on-the-wire rendering formats - while still being able to equate each elemental Lego brick back to its CCTS BIE and hence further better interoperability and information consistency. However for v1.1 CAM - we've had to go to market with a pragmatic compromise. The world (it's not just Ken!!) is XSD-centric. And they also use java tools like XMLBeans - so they have no use for CCTS/BIEs and such - they want that uniform XSD to drive their java tools - and they don't care what else people are trying to introduce. : -( It's the engineers view of XML and eBusiness exchanges - not the information modellers - that dominates here. CAM at least is a halfway house. By having more engineers start to use technologies like CAM - to supplement their XSD - and document the interchange contextual specifics - then we can get the two halves coming closer together - and sharing benefits. CAM provides the modellers the means to handle the information exchanges at a more rule driven and abstract level than raw XSD. Meanwhile CAM provides the engineers with nifty runtime tools that make their job easier - helps partners build better XML to send them - causing their XMLBeans to fail less often - and keeps data analysts happy - because it provides great documentation they can read and verify. We still have more work to do on better registry interfacing - storing BIEs in registry - and enabling tools like CAM to then do more via standardized definitions held in registry and being able to automate mapping across wire formats. In theory a CAM template should be able to accept EDI, "simple-XML", conformant-UBL all equally - and apply a consistent set of business logic checks and rules - to enable the interactions. My mantra has always been "transformation at point of use" - being able to present the correct format contextually and thereby minimizing the impacts across the whole. In practice - we still have some more work to do on all that! But at least we are making progress in the right direction. ; -) Cheers, DW "The way to be is to do" - Confucius (551-472 B.C.) -------- Original Message -------- Subject: SV: SV: [ubl-dev] UBL Basics.. try "Productivity".... From: "Bryan Rasmussen" <BRS@itst.dk> Date: Mon, February 12, 2007 9:07 am To: "Stephen Green" <stephen.green@bristol.gov.uk>, <ubl-dev@lists.oasis-open.org> I'm pretty sure I would want to call it a serialization of the UBL model. such as this is a namespace free serialization of the UBL model, in compliance with CCTS customization rules. Cheers, Bryan Rasmussen -----Oprindelig meddelelse----- Fra: Stephen Green [mailto:stephen.green@bristol.gov.uk] Sendt: 12. februar 2007 14:56 Til: ubl-dev@lists.oasis-open.org Emne: Re: SV: [ubl-dev] UBL Basics.. try "Productivity".... No, that's not right because the context is already there in the BIEs (as distinct from the CCs). Nor is it a recontextualisation since the BIEs are unchanged. It is certainly in the broader sense an implementation. And it is one which CCTS provides for when UBL is itself seen as an implementation of CCTS - in which case UBL should provide for my schema as a kind of implementation of a CCTS-compliant language.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]