[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: VS: [ubl-dev] UBL's role
David, Agreed - the transport layer is not so important - so long as it is able to enforce the business level of delivery agreed upon. And that is the key here - that when a partner signs up to do electronic exchanges - there is some kind of legalize they have to accept - and a formal CPA and details of the required roles, responsiblities, service / actions, communication profiles, process steps and transactions. The power of a tool like CAM is that it can automate the information exchange for small partners. They can pre-test and certify their transactions interactively - when CAM is used as part of an integration registry / portal; and then once OK - switch to production exchanges. Of course integrators may pre-package this into turn-key solutions. However - even then - the partners may wish to know what business requirements and constraints exist. We've designed CAM templates so they can be pretty-printed as FAQ HTML for users to review the actual business requirements. And this highlights the point that Duane was making, and the BCM view - business-centric templates - so that the model can drive the actual production systems - that there is no separation - so that what is agreed to and understood at the business level is the same rules that run the actual exchanges. Then as you say - you are truely replacing paper in its ability to confer understanding and its flexiblity; but - critically - you are improving on paper - since paper can be very inexact (right data / wrong part of the form, etc). DW ----- Original Message ----- From: <david.lyon@computergrid.net> To: <david.scott.stokes@inman.com.au> Cc: <@mail.support1.net>; "'Duane Nickull'" <dnickull@adobe.com>; "'Juha Ikävalko'" <juha.ikavalko@tieke.fi>; <ubl-dev@lists.oasis-open.org> Sent: Wednesday, January 12, 2005 10:10 PM Subject: RE: VS: [ubl-dev] UBL's role > Hi David, > > I think most people would say that it doesn't matter so much > how the message moves from the originator to the recipient. > > This could be ebxml, as an email attachment or on a connection > grid. > > My only comment is that in smaller businesses it is quite > possible that there might be little or no computer validation > of the message itself. > > Smaller companies cannot afford the luxury of getting > custom validation for documents in the way that larger > organisations do. > > If the documents are correct, then they are actioned. If > they are wrong then they are queried and resolved with some > sort of manual intervention. > > This is how the businesses that I see UBL tend to use > it in any case, just as though they were paper docs. > > Best Regards > > David > > > Quoting David SCOTT STOKES <david.scott.stokes@inman.com.au>: > > > 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]