Re: VS: [ubl-dev] UBL's role

[david.lyon@computergrid.net]

Ok, well I don't use CAM right now but it's useful information
to have in any case.

Thanks and have a nice day.

David

Quoting "David Webber \\(XML\\)" <david@drrw.info>:

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




----------------------------------------------------------------