Thanks for the quick note, Scott, but your response raises more questions than
answers for the majority of us on this list who are not in Tokyo. I would
appreciate getting an answer when you have time. Specifically, please elaborate
on not meeting the requirements to pick "a single modeling technique and
methodology, and adopting existing specifications".
I appreciate the need to come to a consensus regarding the TA spec - and that
will probably require several folks resigning themselves to agreeing to
disagree. However, I was not trying to debate issues when I raised my
questions. If you look at the questions again, I am only asking to understand
the basis of your vision and assertions. Please respond when convenient.
Thanks,
Mike
"Nieman, Scott" wrote:
> 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.
>
> Scott
>
> -----Original Message-----
> From: Mike Rawlins
> To: '[email protected] '
> 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
> ever
> > been prompted by your browser that you need to install one of these
> "things"
> > 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
> is
> > 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,
> 10,
> > 15...whatever...it WILL happen. (or should I say YAHP (yet another
> "hype"
> > protocol...EDI -->ASN.1--->XML????)
>
> I may be mistaken, but I think most of us feel that this is a fairly
> obvious,
> 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
> installed.
> > however, based on trading partner A's profile and trading partner B's
> > profile, trading partner A is prompted with a dialog box(message)
> because
> > the tpp / tpa process states that for the specific collaborative
> business
> > process trading partner A needs to install an adapter to talk to
> trading
> > 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
> my
> questions:
>
> 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
> real
> differences in business processes. Do you agree with this assessment?
>
> What is your order of magnitude estimate of the number of different
> business
> 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
> http://www.metronet.com/~rawlins/
--
Michael C. Rawlins, Rawlins EC Consulting
http://www.metronet.com/~rawlins/
