[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Re: BP_Deliverable for QRT review -2
I confess that I only spent a couple of hours with this document and it
deserves more because it is obvious that it embodies a great deal of sincere
effort. I gave up about halfway through because the opinions that I'd gotten
from the first half were getting stronger page by page. I am trying to take
the perspective of someone new to ebxml and I'm repeatedly confused by the
use of terms in different ways than I'd use them in "ordinary business".I
simply don't see how this is grounded in the goals of ebxml or what someone
who encounters it is supposed to do with it. It has taken on a life of its
own.
What I was hoping to find was a clear statement of how this modeling
machinery will help businesses define and express ebxml compliant business
processes. This is inherently an incremental goal. The eco framework
presented this view extremely clearly; it proposed a seven level conceptual
model of ecommerce in which how a business describes the services it offers,
the sequence of document exchanges that invoke and respond from those
services, and the semantic definitions of those documents are clearly
separated. In contrast, this metamodel forces me to swallow an enormous
amount to get any benefits at all. The document says on page iii that
these perspectives support "an incremental model construction methodology"
but that isn't clear to me. I wanted to see some discussion of "core
business process components" but if it is in here I didn't see it.
Maybe I'm just confessing my distaste for the presentation here in which
pseudo-formal clarity takes precedence over readability. But when I tried
to cut through the formality I discovered:
-- outright tautology -- the opening sentence says "business partners must
collaborate..." -- isn't collaboration what makes someone a business
partner?
-- too much jargon for jargon's sake. Why call something a "BOM" (a
Business Operations Map) when 99% of the intended readers of this document
want to map that to "Bill of Materials" (p 1)
-- use of "collaborate" (e.g. page 5) in an underloaded sense to mean
"connected to" or "in response to". Create purchase order and create sales
order don't suggest collaboration. When I go to Amazon.com and buy
something I'm not collaborating with Amazon.
-- use of "Agreement" (p 15) is also nonconforming. An agreement is defined
as not implying any agreement. That's left to the "economic contract"
-- a distinction between "business event" and "economic event" (p. 17) that
I can't penetrate. Why is "taking an order" a business event and not an
"economic event" ("sale" is an example of an economic event). Accepting an
order creates a contract to sell.
How is learning all these specialized and nonconventional terms supposed to
help me become ebxml compliant?
"Paul R. Levine" wrote:
Tim,--This will be very useful for us. Just what we need for now.
Thanks,
Paul Levine
"Tim McGrath" <tmcgrath@tedis.com.au> on 10/12/2000 11:03:01 PM
Please respond to tmcgrath@tedis.com.au
To: "Paul R. Levine" <plevine@telcordia.com>
cc: "'ebXML Coordination'" <ebxml-coord@lists.ebxml.org> (bcc: Paul R.
Levine/Telcordia)
Subject: Re: BP_Deliverable for QRT reviewThe QR Team have agreed to comment on the document personally and informally (as
this is not part of the formal review of this document). We understand that at
some
futue stage this document will be submitted for formal review and any comments
made
at this stage may or may not form part of that review.The comments will available at 08:00 PST on Monday 16th Oct.
I hope this is useful to you
"Paul R. Levine" wrote:
> Tim,
>
> a. As we discussed on the call, this is probably not a formal QR review,
leading
> to a vote. We have additional pieces to integate into it: core components and
> TPA, but not REA as stated on my message. Bob Haugen corrected me my via
> that REA had already been incorporated. It would not be appropriate to vote on
> this specification until it includes core components and TPA.
>
> b. The primary purpose for QR review now is to confirm this specification as a
> substantial baseline for the Tokyo PoC.
>
> Regards,
>
> Paul
>
> "Tim McGrath" <tmcgrath@tedis.com.au> on 10/10/2000 01:05:57 AM
>
> Please respond to tmcgrath@tedis.com.au
>
> To: "Paul R. Levine" <plevine@telcordia.com>
> cc: (bcc: Paul R. Levine/Telcordia)
> Subject: Re: BP_Deliverable for QRT review
>
> before i forward this to QR i would like to clarify a few things...
>
> a. does this need to be a formal QR review? as it only comprises a portion of
> the final document. if we
> were to review sub-sections they would still require to go through 2 review
> cycles with the complete
> document.
>
> b. is the purpose to fast track a specification for the PoC? in which case we
> would be happy to give
> input but i don't think this needs to use a formal QR review cycle. (i shall
> check this with the
> executive)
>
> I shall be attending the BP/CC teleconference this evening maybe we could
> discuss this after that meeting?
>
> Sorry for this hesitation but hopefully we can save everyone some time this
way.
>
> "Paul R. Levine" wrote:
>
> > StC Members,
> >
> > Following up on the 9 Oct. BP PT conference call today, we are submitting
the
> > attached Technical Specification of the ebXML Metamodel, entitled "Business
> > Process Project Team Technical Specification Document Draft Version 3.0:
> > Collaboration Modeling Metamodel & UML Profile" specification for Quality
> > Review. I had previously forwarded this document through Klaus, but he
> reminded
> > me of the correct procedure to go through the StC. This document is
admitedly
> a
> > work in progress, but is the specification that was submitted by Edifecs to
> > ebXML and adopted by the Delivery Team, because of quality and completeness
of
> > the work. Work remaining on this specification is to enhance the modeling
> > metamodel to include explicit Resourcs, Events, Agents (REA), core
components
> > and TPA. The reason this document is being submitted for Quality Review now
> is
> > the AIAG PoC proposal is based on this mature and stable metamodel and the
> > collaborative business patterns contained in it. The second reason is that
> > Draft Version 2.0 of the BP PT Technical Specification Document has been
> > superceded by this document, and thus will be "decommissioned."
> >
> > My apologies to those who are receiving this for the nth time. We're still
> > working on getting a clear path to BP and CC documents on the ebXML web
site.
> > Also many people on the BP call today were in need quick delivery of the
> > document.
> >
> > Thanks,
> >
> > Paul Levine
> > BP PT co-lead
> > (See attached file: ebXML Collaboration Modeling Metamodel.doc)
> >
> > ------------------------------------------------------------------------
> > Name: ebXML
Collaboration
> Modeling Metamodel.doc
> > ebXML Collaboration Modeling Metamodel.doc Type: Microsoft Word
> Document (application/msword)
> > Encoding: BASE64
> > Description: Mac Word 3.0
>
> --
> regards
> tim mcgrath
> TEDIS fremantle western australia 6160
> phone: +618 93352228 fax: +618 93352142--
regards
tim mcgrath
TEDIS fremantle western australia 6160
phone: +618 93352228 fax: +618 93352142
begin:vcard n:McGrath;Tim tel;pager:+61(0)299633829 tel;cell:+61 (0)438352228 tel;fax:+61(0)893352142 tel;work:+61(0)893352228 x-mozilla-html:FALSE adr:;;;;;; version:2.1 email;internet:tmcgrath@tedis.com.au x-mozilla-cpt:;-19376 fn:tim mcgrath end:vcard
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC