OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-dev message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

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 

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 


Peter Harrison
Nothing But Bet Limited

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Search: Match: Sort by:
Words: | Help

Powered by eList eXpress LLC