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!



Arofan:

	I realized that messages weren't what CoreComponents were
developing.  It was my understanding that we were developing the 'lego
bricks' that the messages could be created.  The underlying core
components would be individual legos and these legos could be constructed
to make a core component - or what I think of as an 'information object'.  
Information objects can be used to build messages.

	I, personally, have been a bit confused about who is the intended
audience for ebXML.  The original audience was for SME's.  I believe that
at this point the audience has changed and is software developers.  This
isn't a bad thing but ebXML has been marketed as a global standard for
SME's.  The intended audience is where the confusion lies.

	Most organizations (especially SME's) buy off-the-shelf software.
Current accounting software provides mechanisms for SME's to interact with
their bank and in some cases customers and vendors. For instance, Intuit
already uses XML for these transactions (BTW, it does concern me that
companies like Intuit who have been doing SGML/XML transactions for years
aren't involved in this effort).  It works very well, as long as you are
in a controlled box with 4 sides, a top and a bottom. However, if you try
to go out of the box, this is where the problem begins and extra manpower
(read cost) is needed to drill a hole in the box and push information out.  
Most SME's don't care about EDI, don't even know what the acronym stands
for - they just want to do business in the most efficient, economical
manner.


	Sorry - I digressed!  I think at a minimum we need (1) individual
legos - single components; and (2) blocks of legos - common reusable
information objects.

Betty

/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
Betty Harvey                         | Phone: 410-787-9200 FAX: 9830 
Electronic Commerce Connection, Inc. |        
harvey@eccnet.com                    | Washington,DC SGML/XML Users Grp
URL:  http://www.eccnet.com          | http://www.eccnet.com/xmlug/
/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\\/\/  


On Wed, 25 Apr 2001, Gregory, Arofan wrote:

> Betty:
> 
> I believe we spoke about this exact topic in Orlando, and it certainly came
> up again at other times within CC.
> 
> I have long believed that we are achieving little if anything without
> defining messages that can be supported and used - built, naturally, of the
> harmonized components that *have* been the focus of this work. After all,
> interoperability in today's technology is generally keyed to the message
> level, and not below, from an application's perspective. (Although low-level
> agreement has it's own set of important benefits).
> 
> I also remember being told quite clearly by the ebXML steering committee
> that we would *not* be working on messages in CC.
> 
> At the same time, I get the sense that many people agree with us that
> ultimately - and all other good things aside, as I believe the work CC has
> done is both impportant and useful - a group *will* build such messages out
> of the harmonized core components that have been described.
> 
> I guess that what I don't know is how the existing ebXML executive will feel
> about that effort. I also hope that we can build only one common purchase
> order, and not several. I can easily see many groups going off to build the
> common message, resulting in the same chaos we have today. It would also be
> a shame to waste the capabilities for handling variation represented by the
> run-time extension capabilities of such technologies as XML Schema.
> 
> I guess at this point it's a "wait and see" kind of thing, and I'm sure
> there will be much discussion of this point in Vienna.
> 
> Cheers,
> 
> Arofan Gregory
> 
> 
> -----Original Message-----
> From: Betty Harvey [mailto:ebxml@eccnet.eccnet.com]
> Sent: Wednesday, April 25, 2001 7:59 AM
> To: William J. Kammerer
> Cc: ebXML Core
> Subject: Re: What do people really expect from ebXML? -
> CoreComponents-Transactions!
> 
> 
> 
> William:
> 
> 	Shy! I don't think we have ever met face-to-face but I don't get
> the impression you were ever shy |-).
> 
> 	I have had my head in the trenches lately and haven't had an
> opportunity to read much less communicate my thoughts on ebXML
> initiatives.  I have mostly deleted messages.  However, that this thread
> does interest me.  Some of the groups that I work with are confused about
> how ebXML can help them, if at all.
> 
> 	ebXML, in my mind, has taken on a totally different turn from the
> original concept.  When an individual wanting to learn and understand
> ebXML is told to go read the public documents to get an understanding of
> exactly what ebXML is all about, there is something conceptually wrong
> with this approach. For many years I worked in S&E User Support and found
> it totally rude when colleagues would say RTFM.  Basically, this is what
> we are saying to individuals wanting to understand ebXML.
> 
> 	There are currently over 20 documents available for public review
> (this
> doesn't include the ones that haven't been approved for public review).  
> Is there anyone who has time to sit down an read 20 different documents on
> ebXML and work enough to feed their family?  I don't!
> 
> 	David Lyons specifically asked 'where are the messages' in core
> components.  In my mind this is the same as asking 'where is the beef'.
> 
> 	It has also been said that the 'world doesn't need another
> purchase order'.  No the world needs a 'common' purchase order, as well as
> world peace and a cure for world hunger.  ebXML can solve the 'common
> purchase order' but they can't create world peace, as well as a cure for
> world hunger.
> 
> 	After the Orlando meeting, it was my understanding that core
> components would develop a set of core components that could be used in
> 'common messages'.
> 
> 	Just my 2 cents worth.
> 
> Betty
> 
> /\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
> Betty Harvey                         | Phone: 410-787-9200 FAX: 9830 
> Electronic Commerce Connection, Inc. |        
> harvey@eccnet.com                    | Washington,DC SGML/XML Users Grp
> URL:  http://www.eccnet.com          | http://www.eccnet.com/xmlug/
> /\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\\/\/  
> 
> On Wed, 25 Apr 2001, William J. Kammerer wrote:
> 
> > David Lyon reiterates his demand for XML documents covering the usual,
> > viz., Product Catalogs, Purchase Orders, Invoices/Receipts, Payment
> > Advices, and  Statement of Accounts.  And just as often, he has been
> > reminded that producing business documents was not within the initial
> > scope of ebXML.  As a matter of fact, I remember the pithy quote being
> > bandied about, in the early days of ebXML, to the effect "the World
> > doesn't need another PO."  I never really knew what to make of that, but
> > being painfully shy, I didn't dare ask "what the heck does that mean?"
> > 
> > It does sound like there will be a long wait for these documents coming
> > out of ebXML - first we have to model the process, then "discover" the
> > core components all the way down to the basic elements, etc. etc.  So,
> > if  "It's costing [David] money every day that ebXML is not going," I
> > suggest he take a look at the existing B2B libraries such as xCBL, at
> > http://www.xcbl.org/,  or OAGIS, at http://www.openapplications.org/.
> > 
> > Both xCBL and OAGIS seem to have everything David is looking for, and if
> > my back were against the wall to come up with XML business documents,
> > those are the first two places I'd look. xCBL even says that their
> > versions will be compatible with whatever ebXML comes up with - and
> > assuming a migration path is provided - so using it may provide the path
> > of least resistance and assurance of compatibility.
> > 
> > William J. Kammerer
> > FORESIGHT Corp.
> > 4950 Blazer Pkwy.
> > Dublin, OH USA 43017-3305
> > +1 614 791-1600
> > 
> > Visit FORESIGHT Corp. at http://www.foresightcorp.com/
> > "accelerating time-to-trade"
> > 
> > 
> > 
> > ------------------------------------------------------------------
> > To unsubscribe from this elist send a message with the single word
> > "unsubscribe" in the body to: ebxml-core-request@lists.ebxml.org
> > 
> 
> 
> ------------------------------------------------------------------
> To unsubscribe from this elist send a message with the single word
> "unsubscribe" in the body to: ebxml-core-request@lists.ebxml.org
> 
> ------------------------------------------------------------------
> To unsubscribe from this elist send a message with the single word
> "unsubscribe" in the body to: ebxml-core-request@lists.ebxml.org
> 



[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