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

 


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-core message

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


Subject: RE: What do people really expect from ebXML? - CoreComponents-Transactions!


Hi.

Betty Harvey says "Where's the beef?"  When I talk to my eBusiness
colleagues, who are of every level of expertise, MOST of them think ebXML is
going to solve the problem of the proliferation of "standard" XML message
definitions by coming up with core message definitions.  That's what they
think "Core Components" means.  So, I have to launch into an explanation ...
causing lunch or dinner to digest rather less well than it would otherwise
... and this yields responses like, "Well, if ebXML isn't going to do it,
then we're either going to be stuck with lots of standards, or a lot of
people are going to get stuck tossing out a lot of investment if they one
they placed their bets on ends up in the dustbin."  Which, of course, leads
to the "who do you think will win" discussion.

Having many message-definitions (many standards) for the same basic message
type is a good thing for those who provide mapping and map respository
services.  I've got an increasing number of colleagues who say, "So, what.
We all know now that mapping is a fact of life that will never go away.
Mapping won't cost as much as it did before because there are cool tools and
service providers who will do it for pennies."

Is the existence of multiple message-definition-creating bodies good for the
SME, who just wants a blankety-blank PO?  Well, it depends on what it's
going to cost them to be able to deal with multiple partners using multiple
message definitions.

Whatever the case, no RTFM suggestions, please.  We need sound-bites that we
can conveniently hand to colleagues, so that we can go back to enjoying our
meals.

And one more thing ... the "common PO."

1.  We don't need more than one PO.  Well, we don't need another message
definition standard.  

2.  But, we do need more than one PO.  The problem with the legacy
850/ORDERS solutions was one of 'one size fits all'.  That's the problem.
One EDIFACT ORDERS definition by itself is like having multiple
message-definition standards.  Because there's not one PO type.  There's
standalone PO between known partners for known product, blanket PO, spot-buy
POs, MRO orders, etc.

My two cents.

Speaking of which ... another gentleman gave us his "two Euros" and a
subsequent reply in the thread was with someone who responded with his "two
cents".  Now, if there are multiple message definitions for the same basic
message type, will the transformation-generators be smart enough to know how
to translate from one standard to another while still retaining the correct
semantic meaning?  How many machines know that two Euros = two cents in the
context of these message threads, but that there's serious trouble with the
European economy when we get to the day where two Euros = two cents?  

Hmm.


[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