[
Lists Home |
Date Index |
Thread Index
]
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
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>
> >
> >
> >
>
>
-------------------------------------------------------
|
