ebxml-architecture message

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


Help: OASIS Mailing Lists Help | MarkMail Help
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index]

Subject: RE: Comments on TA version 0.9

sorry Mike, but I don't plan to respond to this today.  I was informed that
in the TA/QRT meeting there was no consensus, except that continuing this
debate would risk delivering the "basic" infrastructure of ebXML.  This will
have to be continued in phase 2.

The requirements to pick "a single modeling technique and methodology, and
adopting existing specifications" will not be met for this phase.


-----Original Message-----
From: Mike Rawlins
To: 'ebxml-architecture@lists.ebxml.org '
Sent: 11/6/00 9:39 AM
Subject: Re: Comments on TA version 0.9

Comments and questions below:

"Nieman, Scott" wrote:

> I find it terrifying to hear that some people do not know the real
> problems....especially at this stage of this initiative.
> Have you ever heard of a "plug-in" or maybe an "adapter"?  Have you
> been prompted by your browser that you need to install one of these
> to view the most updated version of Shockwave?
> PERHAPS this is the architecture?
> Why?  because of the REAL problems!!
> 1) the REAL SME does not give a hoot about technology and it should be
> ABSOLUTELY transparent to them.  Looking at XML versus looking at CODE
> still LOOKING at technology...make it invisible to them or we fail.
> 2) there WILL BE YAP (yet another protocol) in a few more years...5,
> 15...whatever...it WILL happen.  (or should I say YAHP (yet another
> protocol...EDI -->ASN.1--->XML????)

I may be mistaken, but I think most of us feel that this is a fairly
non-controversersial point.

> SOOOOOO....the solution scenario...for those who don't get it...
> trading partner A uses QuickBooks and wants to buy something...looks
into a
> registry and finds trading partner B has a suitable product.  trading
> partner A and trading partner B have the ebXML messaging service
> however, based on trading partner A's profile and trading partner B's
> profile, trading partner A is prompted with a dialog box(message)
> the tpp / tpa process states that for the specific collaborative
> process trading partner A needs to install an adapter to talk to
> partner B.  download the adapter from a ebxml reg-rep with software
> components in it and wa-la!  trading partner b gets a PO.

Scott, thanks for spelling out how you think this is going to work.  Now

Even if we can normalize the data requirements through better modeling
than we
have with traditional EDI, there may still be *many* variations due to
differences in business processes.  Do you agree with this assessment?

What is your order of magnitude estimate of the number of different
process variations, and hence, the number of different plug-ins that
might be
needed for QuickBooks?

Who is going to provide these adapters that A needs to make QuickBooks
talk to
B?    Do you expect Intuit to supply them?   Or, do you expect someone
else to?

Michael C. Rawlins, Rawlins EC Consulting

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index]
Search: Match: Sort by:
Words: | Help

Powered by eList eXpress LLC