[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: Example Scenarios Used Within the Aerospace Industry
I have to agree with Dave Welsh regarding conformance. From our work on
the ebXML Joint Delivery Team, i.e., BP and CC, we laid out a plan for how
the BP top-down business process analysis could utilize the CC bottom-up
core and domain components. This is documented in the bpOVER Technical
Report. However, it should all come together in one metamodel, and that's
one aspect of the ebBPSS that remains to be done. Core and domain
components should be used to develop ebXML compliant business document
payloads within the business process and information model. In the process
of modeling business documents, business information objects (built from
core and domain components) should be created and registered as eBusiness
reference standards so they are accessible and reuseable cross-industry to
the greatest extent possible. Within that framework, the BP work should
adopt the CC work and support the on-going joint activity of the EWG and
X12.
Regards,
Paul Levine
"Welsh, David"
<David.Welsh@nord To: "'tboyle@rosehill.net'" <tboyle@rosehill.net>,
strom.com> Bob Haugen <linkage@interaccess.com>, "'Schuldt, Ron
L'" <ron.l.schuldt@lmco.com>, ebxml-dev@lists.ebxml.org
06/01/01 02:54 PM cc: (bcc: Paul R. Levine/Telcordia)
Subject: RE: Example Scenarios Used Within the
Aerospace Industry
Todd,
>
> But don't slow down the CC vocabulary. I would appreciate an explicit
> vote of confidence from the BP community, for the existing CC
> vocabulary.
Well the ebXML BP team, like all ebXML teams are still morphing into OASIS
or CEFACT bodies; to continue the vision. (catepillar to a butterfly ?!)
Technically calling a "vote" .... !
>
> I see no reason the work on BP should delay the immediate adoption
> of core components vocabulary for the PO, the party, etc. by
> SMEs, in simple HTTP interactions, TODAY. These interactions are
> already spreading rapidly in non-standard vocabularies, both within
> collaboration frameworks and outside them. This proves the viability
> of custom HTTP interactions with something like biztalk server.
>
In ebXML, when you get down to the lower level of the UMM BP metamodel, a
BP
also specifies which 'payload' details need to handled. 'payoads' can be CC
or traditional EDI or ... They are all 'payloads' of business information
to
support the BP. Further my take is CC will become more 'efficient payloads'
to support a modeled BP.
> In other words, the BP layers under construction should
> conform with existing vocabulary which is being implemented
> within the business document level. Does the BP layer require
> changes in the party.details, quantity.type, identifier.type, etc.
> in the CC excel spreadsheet?
>
To be clear, BP drives the need(s) for payloads (details) to support the
collaborating BP; along with other technical transport criteria --
'reliable
messaging required', or .... So I think you mean it's the other way round
re. 'conformance' !
All the best
Dave Welsh
> Todd
>
>
> > -----Original Message-----
> > From: Bob Haugen [mailto:linkage@interaccess.com]
> > Sent: Friday, June 01, 2001 10:18 AM
> > To: 'Schuldt, Ron L'; 'ebxml-dev@lists.ebxml.org'
> > Subject: RE: Example Scenarios Used Within the Aerospace Industry
> >
> >
> > Ok, I love it. The AIA PO example cited below is a perfect
> > example of how to think about this stuff. It's not just the
> > PO (as if you are sending one document all by itself,
> > it's the whole business collaboration with all of the
> > documents in a reasonable sequence with relationships
> > between them, so it becomes clear what goes together
> > with what and why.
> >
> > -Bob Haugen
> >
> > -----Original Message-----
> > From: Schuldt, Ron L [SMTP:ron.l.schuldt@lmco.com]
> > Sent: Friday, June 01, 2001 11:49 AM
> > To: 'ebxml-dev@lists.ebxml.org'
> > Subject: Example Scenarios Used Within the Aerospace Industry
> >
> > The Aerospace Industries Association (AIA) has been
> developing harmonized
> > business transaction implementation conventions for the past
> > several years.
> > To support each transaction type (e.g., purchase order,
> purchase order
> > change, etc.), the AIA EC Working Group starts with
> business example use
> > case scenarios that are documented and agreed upon by the
> participating
> > companies within the industry.
> >
> > Although the data details are EDI X12 oriented, the business process
> > scenarios would apply to any data format standard. Therefore, I
> > suggest that
> > members of this list at least look at the "business
> example" documents
> > available from the following URL: --
> > http://www.aia-aerospace.org/edi/implcon.cfm
> >
> > For starters, I suggest looking at the purchase order business
> > example which
> > is particularly useful. Portions of it could provide a model that
> > this list
> > might find useful.
> >
> > Ron Schuldt
> > Lockheed Martin Enterprise Information Systems
> >
>
>
>
>
> > -----Original Message-----
> > From: Bob Haugen [mailto:linkage@interaccess.com]
> > Sent: Friday, June 01, 2001 7:58 AM
> > To: 'Miller, Robert (GXS)'; David RR Webber
> > Cc: ebXML Core
> > Subject: RE: where the qualifiers went...
> >
> >
> > Robert Miller wrote:
> > >I hope and believe that the EWG/X12 effort will adopt a top down
> > approach to
> > >Core Component design that will produce significant
> results by the end of
> > >this year.
> >
> > Some of us were talking in Vancouver about the unification
> of business
> > process and information models. We didn't get very far on
> it yet, but
> > immediately it clarified all kinds of issues about core components
> > and business documents and their actual use in conducting
> > electronic business.
> >
> > For example, considering the stages of a business transaction in
> > Open-EDI: identification, planning, negotiation (of commitments),
> > actualization (fulfilling commitments), and post-actualization
> > (returns, service, etc.). The information model must be consistent
> > in structure and content across all stages. Moreover, at each
> > stage there are particular information structures that are
> critical -
> > for example, commitments require who, what, when, how much,
> > where, etc. And there are essential relationships between
> > information elements at different stages: fulfillments vs
> > commitments, etc.
> >
> > If the above is too abstract for you,
> > commitment = PO Line Item
> > fulfillment = Product Delivery
> > etc.
> >
> > Also, to agree with Mr. Miller, it really will help to model
> > all this stuff in as syntax-neutral way as possible (e.g. UML).
> > CIDX is a chemical industry standards group that modeled
> > all their stuff in UML and derived DTD's automatically.
> > Now they want to move to XML Schema and it's just
> > a matter of some new production rules.
> >
> > I hope the EWG/X12 effort will consider business processes
> > as well as information elements. I'll be there for a while
> > Tuesday and Wednesday and would be interested in talking
> > to anybody who wants to continue this discussion in person.
> >
> > Regards,
> > Bob Haugen
> > 708-524-1436
>
>
>
> ------------------------------------------------------------------
> To unsubscribe from this elist send a message with the single word
> "unsubscribe" in the body to: ebxml-dev-request@lists.ebxml.org
>
------------------------------------------------------------------
To unsubscribe from this elist send a message with the single word
"unsubscribe" in the body to: ebxml-dev-request@lists.ebxml.org
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC