RE: [ebxml-dev] RE: [EDI-L] Article on ebXML Core Components ...

["Vadhri, Srinivas" <Srinivas.Vadhri@commerceone.com>]

Title: RE: [ebxml-dev] RE: [EDI-L] Article on ebXML Core Components ...

Try

http://www.oasis-open.org/committees/ubl/

or

www.xcbl.org

both have schemas for various documents.

regards

Srinivas Vadhri

-----Original Message-----
From: Rachel Foerster [mailto:rachelf@ix.netcom.com]
Sent: Monday, April 22, 2002 4:37 PM
To: 'Peter Harrison'; al.kassam@briyante.com
Cc: ebxml-dev@lists.ebxml.org
Subject: RE: [ebxml-dev] RE: [EDI-L] Article on ebXML Core Components
...

Peter,

Right on and bingo!

However, the UBL effort is doing  just what you've asked for: standard
XML-based documents, such as purchase orders, invoices, advance ship
notices. I believe the first draft of the first document is available...I
read it on the list (!!, but which one I can't recall) so I bet someone here
will post a link to get it.

Rachel

-----Original Message-----
From: Peter Harrison [mailto:peterha@nothingbutnet.co.nz]
Sent: Monday, April 22, 2002 4:24 PM
To: al.kassam@briyante.com
Cc: ebxml-dev@lists.ebxml.org
Subject: Re: [ebxml-dev] RE: [EDI-L] Article on ebXML Core Components
...

On Tuesday 23 April 2002 08:49 am, you wrote:
> Peter, we've solved the problem of common formats by providing a very
> powerful schema translator that can translate incoming and outgoing
> messages as needed to suit the eventual consumer.  The rest of the
> eBusiness problems are being addressed using ebXML.

When I first joined this group I would have accepted this... however it is
clear that this doesn't solve anything at all.

Accounting Software companies already have translators - not only for XML -
but to handle just about any text format. They need to because there are so
many different file formats. The problem these companies have is that there
is no standard.

The question you should be asking is why you need to translate something as
simple as an invoice at all? Why introduce all the complexity and problems
of
translation when you could simply define a standard invoice schema up front?

I know this standard invoice won't suit General Motors or whatever, but
perhaps they can inherit from the standard schema and extend it. At least
then the basic elements are still understood explicity by any organisation
without downloading a specific FordMotors invoice schema.

To be widely adopted by SME's the technology needs to be as easy to use as
email. They will want to create an invoice/order and send it no different
from they do now in their accounting systems. Why should they pay for
translation services (presumably thats what we are talking about here) when
a
simple format would make life easier and simpler to implement. Why should
sending an invoice be and different to sending a word file - word files
being
much more complex than a simple XML invoice.

I seem to hear many arguments why electronic transfers are so difficult -
but
I have a working system - with open source libraries accounting system
companies could use - which has been written in my own 'spare' time after
hours.

Sure I don't work for a large corporate and don't know the difficulties and
issues they have, but I don't see why a solution that would work for 95% of
small businesses needs to solve all the issues for corporations.

I mean - could you imagine a web system where you had to negociate
translation of your protocol with a web site via a third party before you
could view its pages? What possible utility does this translation serve?

- Like I said before, each company has its own existing translation code -
my
issue is whether it is better to develop an actual standard schema rather
than creating 'standard translators'.

Sorry if this is too much of a rant, but I am very frsutrated that there is
still no serious effort to create simple effective business XML schemas and
transports.

Regards,

Peter Harrison
Nothing But Bet Limited
http://www.nothingbutnet.co.nz

----------------------------------------------------------------
The ebxml-dev list is sponsored by OASIS.
To subscribe or unsubscribe from this elist use the subscription
manager: <http://lists.ebxml.org/ob/adm.pl>

----------------------------------------------------------------
The ebxml-dev list is sponsored by OASIS.
To subscribe or unsubscribe from this elist use the subscription
manager: <http://lists.ebxml.org/ob/adm.pl>