[regrep-cc-review] Conference Call Agenda

["CHIUSANO, Joseph" <JCHIUSANO@lmi.org>]

Title: Conference Call Agenda

Hi All,
Here are call details and an agenda for our call today...looking forward to talking with you all then!
Thanks,
Joe
Call Details:
CALL DATE: MAR-06-2002 (Wednesday)
CALL TIME: 02:00 PM EASTERN TIME
DURATION: 2 hr

USA Toll Free Number: 800-779-6816
PASSCODE: 80170
LEADER: Ms Lisa Carnahan
Agenda:
1. Questions on last meeting's minutes
2. Minutes taker for this call
3. Discuss Mark Crawford's response to eBTWG questions
<<RE: Core Components Specification Questions>>
4. Version 1.8 of CC spec - comments/questions?
5. Functional points mapping - discuss latest document and next steps:
<<CC Spec-Registry Functional Points - MASTER.doc>>
6. UML vs. XML - do we need an association between the UML representation of an object and its XML representation? - reference Duane Nickull's e-mail of yesterday:

<<Re: [regrep] minutes of last meeting>>
7. Other items
8. Next call - date/time, goals, etc.

**************************************************************************
  Joseph M. Chiusano
  Logistics Management Institute
  2000 Corporate Ridge
  McLean, VA 22102
  Email: jchiusano@lmi.org
  Tel: 571.633.7722
**************************************************************************

---

• From: "CRAWFORD, Mark" <MCRAWFORD@lmi.org>
• To: "CHIUSANO, Joseph" <JCHIUSANO@lmi.org>
• Date: Mon, 25 Feb 2002 06:24:13 -0500

Title: RE: Core Components Specification Questions

>
> 1.      Context categories (Product Classification, Industry
> Classification, etc.) - is it anticipated that these will be
> pre-populated in a ebXML Registry implementation (i.e. "packaged" with
> the registry)?  Or would they be entered into the registry by the
> implementer?

The eight categories are fixed and should be accounted for in setting up stored requirements, actual content will be populated by people registering.

>
> 2.      Assembly of MIG, Schema, XML DTD - is it anticipated that this
> will be done by the Registry (i.e. an assembly engine)?  Or would the
> Registry simply store the assembly rules and therefore the assembly
> would be executed by a product external to the Registry?

Outside the scope of CC.
>
> 3.   There are multiple references to registering re-use (ex:
> a Business
> Process).  Regarding this registration:
>
>          - What purpose does this serve?  Is it solely for metrics?

Lets folks know who is using core component and in what context(s).
>
>          - What metadata should be associated with this re-use (i.e.
> date, time, user, etc.)?

See section 7.
>
>          - If re-use is for metrics:  should these metrics be
> defined by
> the Registry architecture?  Or, should the metrics be  gathered from
> outside the Registry?

not metrics.
>
> 4.   p.20: Step 2 states "Focus on a particular data exchange
> within the
> Business Process...".  Should the Registry store data
> exchanges as well
> as business processes?  If so, what is the required metadata
> for a data
> exchange?

This is in a non-normative section (read section 4 intro). All metadata requirements are already included in Section 7.  Suggest you focus on that section.

>
> 5.   p.23: Step 1 states at top "...for an existing Aggregate Business
> Information Entity that has the same definition.".  What does
> "definition" mean in this case?  Is this a description?  Or is it a
> particular set of metadata?

This is in a non-normative section.
>
> 6.   p.83: Association Type - there are several types listed
> (aggregation, specialisation...).  Is the Registry required
> to know all
> possible Association Types?  If so, is a complete list available?

Yes it is.  Only those listed.
>
> 7. p.84: Association Start Date/End Date - what is the
> purpose of these
> attributes?  Our current Registry architecture does not include these
> attributes for Associations, therefore it is currently not possible to
> define the action to be taken upon expiration (if any).

Necessary for future assembly.  You need to add the attributes.
 

---

CC Spec-Registry Functional Points - MASTER.doc

---

• From: Duane Nickull <duane@xmlglobal.com>
• To: Lisa Carnahan <lisa.carnahan@nist.gov>
• Date: Tue, 5 Mar 2002 16:44:36 -0500

Title: Re: [regrep] minutes of last meeting

Lisa Carnahan wrote:
> 1. CC Review Update - the CC Review Subteam is continuing its work in
> pulling out the registry requirements/expectations from the CC Technical
> Specification.  The Subteam is developing a table that defines each
> requirement.  For each requirement the subteam is further defining how the
> V2 RIM/RS satisfies the requirement, or indicates if the specs do not
> satisfy the requirement.  Currently the Subteam does not see any
> 'showstoppers'.  The Subteam meets the Wednesday (2:00 Eastern) prior to
> the TC meeting on Thursday.
>>>>>>>>>>>>>

Lisa et al:

I have some concerns about the above statement.  The CC team just
released v 1.80 of their current spec which utilizes an outdated UML RIM
diagram from the old Registry Specification. 

There are also some issues that the UN/CEFACT eBusiness Architecture
team has identified as use cases for registries based on unique needs of
core components and BIE's that the CC team has not acknowledged yet.

I would therefore like a representative from the Archtiecture team to be
involved with this process if possible. 

From what our initial analysis is,  we believe that the Registry,
specifically the associations and classifications, is adequate for
meeting all the needs of ebXML Core Components and BIE's. 

The CC team has some important questions posed to them which they
haven;t answered yet.  The most critical one is "What does the Registry
yeild or point to when it is asked for a Core Component (or BIE)?"  We
have suggested an XML artifact and others have suggested a UML artifact.
Both are different expressions of the same artifact but the UML will not
meet the needs of the users by itself.  The UML, with the Regsitry
Information Model, will meet the needs of the users IF, and only if,
there is also an XML expression of the same artifact that is pointed at
by the regsitry via way of an "Association".

Some things the archtiecture team has identified as use cases are:

1. Querying the Regsitry for all BIE's that are associated by virtue of
the fact they were created from a single Core Component (needed for
design time to avoid rampant and uncontrolled duplication of BIE's)

2.  Querying the Regsitry for a BIE and finding what other BIE's are
related to it by way of RIM associations.

3.  Finding a parent (Master) copy of a Core Component in another
registry as a result of a registry query.

There are more but I don;t want to bore/excite you all with the details
as of yet.

Best wishes

Duane Nickull

>
> 2. Method for handling public comments - The TC developed a method for
> handling public comments regarding the V2 RIM/RS.  (As of the meeting,
> there had been only one set of comments.)  Comments will be resolved by a
> subteam of TC members using a mailing list.  Initial volunteers for the
> subteam are Nikola, Farrukh and Sanjay.  Farrukh volunteered to identify
> the comments and uniquely number them. (Duane's comments came via our
> regular mailing list, rather than the official comment list - therefor, we
> need to be sure to formally identify comments from all sources.)
>
> 3, V3 Priorities - The team reviewed the list of candidate items for V3
> work.  Neil Smith will make (has made?) the agreed changes to the
> list.  Most of the changes were either renaming changes or consolidation
> changes.  The following members listed their priorities/interests based on
> the list (prior to any changes):
> Farrukh - 12, 7, 18, 5, 8
> Nikola - 11
> Sanjay - 10, 6, 15
> Lisa and Sally - 3
>
> Anyone else with an opinion regarding priorities should send email to the list.
>
> 3. Criteria for determining V3 Work items - The TC discussed some
> subjective criteria that we should use in discussing our priorities of work
> items.  The following list was developed: (no implied relevance to order)
> -Maturity of base specifications on which our specifications may rely.
> -Ease in which the item may be addressed given the V2 specs (low lying fruit)
> -Level of effort required versus payoff of addressing
> -The Use case for the item
> -Level of interest by TC members to address item
>
> 4. We will be discussing (and hopefully) making initial decisions regarding
> our top items at the next conference call.  Our goal is to have initial
> proposals done by April 15.
>
> 5 Next conference call is Thursday, March 7th.
>
> ----------------------------------------------------------------
> To subscribe or unsubscribe from this elist use the subscription
> manager: <http://lists.oasis-open.org/ob/adm.pl>

--
CTO, XML Global Technologies
****************************
Transformation - http://www.xmlglobal.com/prod/foundation/
ebXML Central - http://www.xmlglobal.com/prod/central/

----------------------------------------------------------------
To subscribe or unsubscribe from this elist use the subscription
manager: <http://lists.oasis-open.org/ob/adm.pl>

---