[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: VS: [ubl-dev] UBL's role
David, Exactly so. From the UBL side you can infer context and role, but you need the other parts of the solution stack to complete the interchange picture - and now CPA, BPSS, ebMS are all providing support for roles, context, service and action, and this then can be used to select and apply the appropriate CAM templates. But as David Lyon noted - the actual exchanges can be agnostic to the transport method (although obviously ebMS is the bell-weather), so long as the transport provides the agreed to profile of features to ensure an accurate, reliable and secure exchange occurs. This can include webservices where they can meet the mission requirements - typically this is best today for synchronous simple information requests that often occur prior to the start of a formal business process - such as stock availability checks. In this regard realtime EDI / RPC and WSDL share much of the same role and performance envelope / characteristics. Cheers, DW ----- Original Message ----- From: "David SCOTT STOKES" <david.scott.stokes@inman.com.au> To: "'David Webber (XML)'" <david@drrw.info>; "'Duane Nickull'" <dnickull@adobe.com>; "'Juha Ikävalko'" <juha.ikavalko@tieke.fi> Cc: <ubl-dev@lists.oasis-open.org> Sent: Wednesday, January 12, 2005 9:45 PM Subject: RE: VS: [ubl-dev] UBL's role Hi David, I like where you are going. I was happy with needing more than: * XML / XSD * CAM (Content Assembly) * Registry (versioning and advertising?) But I can't see the bit that moves the message from the creator's database to the recipient (probably another database). Content validation and Business Rule Checking would also be good, along with possibly also producing a rendered human readable document. This activity requires orchestration, workflow and messaging. Are these just assumed in this context, or should we add it to the list of components needed before we "bake and eat"? Regards David SCOTT STOKES IT Specialist Chartered Accountant PMP MACS Director - Information Management Australia Pty Ltd david.scott.stokes@inman.com.au www.inman.com.au Mobile: +61 417 531107 in Australia and global roaming Fax: +61 3 9923 6411 -----Original Message----- From: David Webber (XML) [mailto:david@drrw.info] Sent: Thursday, 13 January 2005 1:07 PM To: Duane Nickull; Juha Ikävalko Cc: ubl-dev@lists.oasis-open.org Subject: Re: VS: [ubl-dev] UBL's role Duane, You touch on the right points - but draw some wrong conclusions! I liked >>> > DN - Most software manufacturers adhere to something called MVC. > Model-View-Control. <<< and >>> You should have a solid core set of functions working on tokens that > represent values from UBL instances and read those in via some sort of > UBL tokenizer class. <<< This is indeed what we are enabling with CAM and the business noun semantic rule storage as neutral XML in registry. "Slurping them in" is then part of what engines such as jCAM can then do - and action that syntax as if it were part of the original inline local template rules all along. Dynamic and context driven validation and assembly. Now this brings us to your premise >>> >"UBL's objective is to become a standard message format for a horizontal exchange of B2B documents. > > > DN - think beyond "documents". Architecturally, a document is only a > collection of data instances and becomes a document when presented and > viewed as such. <<< What we learned from EDI is that this in practice just does not work out like that. Essentially in EDI you have structures (EDI transactions) and then all the "how to" is contained in IGs and ICs - Implementation Guides (which is the formal standard view of the world) and the Implementation Conventions - derived from the IGs - which is what the partners agree to do in reality between themselves. This leads to a merry dance, when the EDI changes, the IGs change and the ICs then must change. So just publishing XSD schema for UBL does not do more than giving people EDI transaction layouts. With XML and XSD and CAM and Registry used together - then you can automate this entire end-to-end sequence and remove the humans and programming hardcoding out. You also achieve alot more - such as making the business agreements transparent and based on known quantities that all parties can verify. Anyway - we're getting ahead of my PPT slides here that I promised for Friday! Basically though - UBL based solely on XSD is only a third of the raw ingredients that you need to really make an eBusiness recipe that people can bake and eat. UBL as the "simpleEDI" story - recast as XML is a start point. It's helpful - but it needs more to make it a complete and tasty meal. Cheers, DW
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]