david.lyon@computergrid.net wrote: > > I've been following ebxml for a few years now, and just reflecting the comments > of others, I too am wondering where ebxml is going ? > > So far, most of the implementations that I've seen require somebody with a list > of degrees and maybe a phd to setup, install and run. That's ok if ebxml is > going to be simply an academic pursuit. > > But in the real business world, things are somewhat different. > > After the hype of dot coms, business is bustling away, and looking for good > tools and new things. Companies are spending on IT again. > > ebxml history gives the strong impression of being just the part-time hack of > some good engineers but in the end, it never worked. There is nothing wrong > with that. > > I'm wondering if there is any 5 year plan for ebxml ? and where to next ? and The closest thing to this at this time is the (relatively new) OASIS ebSOA TC[1], which is proposing as part of its charter to "take ebXML into 2004" and update its architecture to better reflect the many advancements that have taken place in the Web Services world over the past several years, and to describe how ebXML can function as a service-oriented architecture. The TC is still working on more concretely defining its scope, mission, audience, etc. - one of the things that it is struggling with (IMO) is how "ebXML-centric" the resulting deliverables might be, vs. how well they can be applied in a "non-ebXML" world. Kind Regards, Joe Chiusano Booz | Allen | Hamilton Strategy and Technology Consultants to the World [1] http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=ebsoa > what about addressing the real needs of the people, how to use it to get > customers to pay money for it etc. These things seem a long way off and yet > these are the things that are really important to most of the people that I > know. > > Regards > > David > > Quoting Rick Marshall <rjm@zenucom.com>: > > > i haven't been able to get into ebxml yet because i don't think it has > > yet really solved the problems of edi. and this is very relevant to the > > soap/uddi people. > > > > the problem with edi is that it is a huge standard encompassing just > > about every aspect of electronic trading and can cope with just about > > every trading relationship. which means 90% (my guess) of it is not > > needed in any particular trading instance. > > > > so industry trading groups sit down and agree on which parts of the > > standard they will use, and how they will use them. typically the > > largest purchaser in a trading group will dominate and determine how > > these things will be done. > > > > then everyone else sits down with interpreters and tools and makes sure > > they can interpret the necessary bits correctly. > > > > as an aside, there's a lot of redundancy in many of the message formats too. > > > > it also forces everyone to learn how to deal at the most complex level..... > > > > i have yet to see any evidence that ebxml has made this simpler, or > > indeed can make it simpler. i can't see how it reduces the trade group > > needs to negotiate the semantics of the messages, the specific use of > > different terms. and now before you can even start to interpret messages > > you need to fully describe your business model. > > > > i reckon the horse has become a camel, and like the camel now has it's > > own evolutionary path. > > > > the good news is that it takes so long for multi-billion dollar trading > > groups to move core technologies i'll probably retire before i have to > > face the reality of this one. > > > > rick > > > > bry@itnisk.com wrote: > > > > > Whenever one examines one of the ebxml specs or reads an article on the > > subject > > > there is likely to be a reference to how edi had problems with being > > accepted > > >because it was too complex, but luckily ebxml, being based on xml, solves > > all > > >this. A very suspect class of assertion it seems like to me. I'm wondering > > if > > >anyone who has familiarity with these technologies can clarify exactly how > > and > > >in what ways ebxml reduces the complexity of edi. > > > > > >Basically my understanding is that ebxml just wrapped the edi model in xml, > > so I > > >have a hard time seeing how it could be simpler. > > > > > >Also am wondering about CPAs in Ebxml, it strikes me that this process > > could > > >actually be somewhat onerous, does anyone know of any case studies etc. on > > >problems with making CPAs between two companies? > > > > > > > > > > > > > > >----------------------------------------------------------------- > > >The xml-dev list is sponsored by XML.org <http://www.xml.org>, an > > >initiative of OASIS <http://www.oasis-open.org> > > > > > >The list archives are at http://lists.xml.org/archives/xml-dev/ > > > > > >To subscribe or unsubscribe from this list use the subscription > > >manager: <http://www.oasis-open.org/mlmanage/index.php> > > > > > > > > > > > > > > > ------------------------------------------------------- > > ----------------------------------------------------------------- > The xml-dev list is sponsored by XML.org <http://www.xml.org>, an > initiative of OASIS <http://www.oasis-open.org> > > The list archives are at http://lists.xml.org/archives/xml-dev/ > > To subscribe or unsubscribe from this list use the subscription > manager: <http://www.oasis-open.org/mlmanage/index.php> > > ----- End forwarded message ----- > > ------------------------------------------------------- > > The ebxml-dev list is sponsored by OASIS <http://www.oasis-open.org> The > list archives are at http://lists.ebxml.org/archives/ebxml-dev/ > To subscribe or unsubscribe from this list use the subscription manager: > <http://www.oasis-open.org/mlmanage/> -- Kind Regards, Joseph Chiusano Associate Booz | Allen | Hamilton The ebxml-dev list is sponsored by OASIS <http://www.oasis-open.org> The list archives are at http://lists.ebxml.org/archives/ebxml-dev/ To subscribe or unsubscribe from this list use the subscription manager: <http://www.oasis-open.org/mlmanage/>
<<attachment: winmail.dat>>