[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: [regrep-cc-review] RE: Core Components Specification Questions
Mark,
Thanks for covering all of our questions.
CC Review Team, please see Mark's responses below. Let's discuss here on the listserv.
Regards,
Joe
> **************************************************************************
> 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