RE: 13 Mar. Conf Call followup: BP Reqmts

["Cunningham, Robert" <CunninghamR@MTMC.ARMY.MIL>]

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/