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

[david.lyon@computergrid.net]

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




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