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

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