[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 ...
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>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC