Re: 13 Mar. Conf Call followup: BP Reqmts

[Mike Rawlins <rawlins@metronet.com>]

Not sure.  Anyone on the BP team care to comment on this?  We have specifically
identified other glossaries, particularly those related to the BP meta-model.
If we can't say exactly what it means and be more specific, we need to take it
out.

Mike

"Cunningham, Robert" wrote:

> Mike and/or Bob,
>
>         or anyone else...
>
>         What is meant by "* Create a glossary of XML tags." ?
>
> Bob Cunningham
> Military Traffic Management Command
> 5611 Columbia Pike
> Falls Church, VA
> (703) 681-5702
>
> -----Original Message-----
> From: Mike Rawlins [mailto:rawlins@metronet.com]
> Sent: Wednesday, March 22, 2000 11:35 AM
> To: Bob Haugen
> Cc: ebXML-BP@lists.oasis-open.org
> Subject: Re: 13 Mar. Conf Call followup: BP Reqmts
>
> Just a note to let you know your comments have been received.  We'll be
> responding to them soon.
>
> Mike
>
> Bob Haugen wrote:
>
> > One of the topics in the conference call was (loosely)
> > what are the requirements for the BP metamodel?
> > Or more generally what are the requirements for
> > the BP group?
> >
> > Here are some selections from the ebXML Requirements
> > Specification V 0.50 that may suggest either overlapping
> > requirements among groups, or requirements from other
> > groups for BP deliverables.  Some email excerpts follow,
> > along the same theme.
> >
> > <comment>
> > my comment
> > </comment>
> >
> > <requirements selections>
> > 3.3  Business Process
> > The Business Process Project Team detailed requirements and deliverables
> > will: -
> > * Provide a high-level business process methodology in terms of XML, e.g.,
> > DTD.
> >
> > <comment>
> > My understanding was that "methodology" had been removed from the
> > group's name and goals, and that "business process model" was the
> > revised goal.  Is this true?
> > </comment>
> >
> > * Select a methodology with which to specify "vertical" business processes
> > according to a uniform "template" (i.e., ebXML "superset") to support
> > comparison.
> > * Explicitly specify the ebXML "superset" business process meta-model. In
> > no instance shall this meta-model be subject to implied specification
> using
> > instantiations or derivations.
> >
> > <comment>
> > Mike Rawlins wrote:
> > > there may still be some sections that have overly detailed,
> > > technical terms and jargon.  Things like "In no instance shall this
> > > meta-model be subject to implied specification using instantiations or
> > > derivations" come to mind
> > </comment>
> >
> > * Incorporate cross-industry methodologies for specifying business
> > processes, e.g., Open Applications Group (OAG), RosettaNet, Health Level
> > Seven (HL7), into the ebXML "superset."
> > * Specify reusable objects.
> > * Create  a glossary of terms related to business process methodology:
> > vocabulary,- e.g., such as functional, non-functional, vertical, message,
> > segment, data type- shall be created and maintained using UN/CEFACT TMWG
> > Unified Modeling Methodology document Annex 1 as a start.
> > * Create a glossary of terms specific to each business process to be
> > modeled.
> > * Create a glossary of XML tags.
> > * Support language neutral mechanisms for associating business
> vocabularies
> > to repository semantic definitions.
> > * Be developed in conjunction with the Registry and Repository Project
> Team
> > to incorporate technical specifications, models, and required glossaries
> > into the ebXML repository.
> >
> > 2.5.1 Architecture
> > * Common Business Processes - Both entities involved in the exchange of
> > data must be engaged in executing the same transaction in the context of a
> > business process.
> > * Common Semantics - Common meaning, as distinct from words, expression,
> or
> > presentation.
> >
> > 3.4 Technical Architecture Project Team
> > * Provide and support a library of common, standard intra-business
> > processes
> >
> > 3.5 Core Components
> > * Identify a methodology for describing core components
> >
> > 3.7        Registry and Repository
> > * a glossary of terms related to business process methodology: vocabulary
> > (e.g., functional, non-functional, vertical, message, segment, data type
> >  using TMWG Unified Modeling Methodology document Annex 1)
> > * a glossary of terms specific to each business process to be modeled
> > </requirements selections>
> >
> > <email excerpts>
> > Here are some excerpts from emails that suggest other overlaps
> > or cross-group requirements:
> > Scott Neiman wrote:
> > | I could search across all DataElementName values for *Purchase*
> > (wildcard=*)
> > | and find a boatload of definitions and associated information.
> >
> > Terry Allen replied:
> > >That would be a Bad Idea because you'd be relying on naming conventions.
> > >What you want to is search for data elements that are somehow related to
> > >the "Purchase" taxon in some classification scheme.
> >
> > >From another email by Terry Allen:
> > >the set of related data may not be the same as the distribution.
> > >It's more like a node in a taxonomy (or other classification)
> > >of DTDs.  We can make this something abstract (that is, not
> > >any of the registered items).  It would correspond to the notion
> > >of a literary work:  the Bible is a literary work with
> > >many versions and physical instantiations, none of which is
> > >primary in the way a book's first edition can be.  Robin, is
> > >this what you have in mind?
> >
> > >We might instantiate this notion as the name of an item in
> > >a classification scheme, so that "Docbook DTD" would be such
> > >an item.  Note that this classification scheme would not be
> > >the same as the subject matter classification scheme we know
> > >we need.
> > </email excerpts>
> >
> > <comment>
> > My point here is not to suggest which group should do what;
> > it is that there are several groups with metadata or classification
> > or glossary or metamodel or process model requirements
> > that (at least) should be mutually consistent.
> > </comment>
> >
> > Make sense?
> > Bob Haugen
>
> --
> Michael C. Rawlins, Rawlins EDI Consulting
> http://www.metronet.com/~rawlins/

--
Michael C. Rawlins, Rawlins EDI Consulting
http://www.metronet.com/~rawlins/