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

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