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

["David Webber \(XML\)" <david@drrw.info>]

No worries mate.

I'll keep the tinnies cold in the fridge ready and
the glasses in the freezer just in case.

Cheers, DW

----- Original Message ----- 
From: <david.lyon@computergrid.net>
To: <@mail.support1.net>
Cc: <ubl-dev@lists.oasis-open.org>
Sent: Thursday, January 13, 2005 8:37 AM
Subject: Re: VS: [ubl-dev] UBL's role


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