OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

regrep-cc-review message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Subject: [regrep-cc-review] RE: Core Components Specification Questions

Title: RE: Core Components Specification Questions


Thanks for covering all of our questions.

CC Review Team, please see Mark's responses below.  Let's discuss here on the listserv.


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

-----Original Message-----
From: CRAWFORD, Mark
Sent: Monday, February 25, 2002 6:24 AM
To: CHIUSANO, Joseph
Subject: 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.

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Powered by eList eXpress LLC