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] | [List Home]


Subject: Re: [regrep-cc-review] Re: Mapping Patterns


<Quote1>
** Am I missing some concepts??
</Quote1>

I think this is great - Diego, I would recommend holding that thought
and we will definitely revisit it as we progress (hope that's ok with
you). For now, I think we should concentrate on the highest-level
details - i.e. the fact that we need to have specific ObjectTypes for
Core Components. Once we get to looking at this at a deeper level,
you're posting below will be very valuable.

<Quote2>
[1] *Not used*!! In my implementation I do not store an Association
CC/BIE. I simply associate 2 aggregates with 'Contains'. Not needed???
</Quote2>

I agree with your assessment. Folks, Diego is referring to the
"Association Core Component" (ASCC) entity in CCTS (see p.11 for the
initial reference). It looks to me as well that we should handle this
with Associations rather than a stored object.

<Quote3>
[2] We used the concept of candidate so that 'our' CoreComponents
could be somehow replaced by CoreComponents from the catalog.
</Quote3>

Sounds like the Life Cycle Manager could also be used for this, through
an object status rather an ObjectType.

<Quote4>
[3] Not present in my implementation but I see the need for it now.
For instance, to store localized enumeration/regexps. BIEs have
Contexts (Classifications) that could define the region where they
should be used.. Same CC, different BIE for different region,
different DataType, but still same CCT.
</Quote4>

Glad you brought this up - the issue of whether or not Data Types should
be stored as Registered Objects or be represented as metadata attributes
for Registered Objects will be a big one for us.

<Quote5>
And what about Contexts? Do they need a pattern too? I've used RIM's
Classification mechanism for Contexts so that each Context Category
has it's own ClassificationScheme.
</Quote5>

I agree with this approach.

Joe

Diego Ballvé wrote:
> 
> > By defining a hierarchty within the ObjectType scheme for CCTS maybe.
> 
> Yep. That's what I've done.  Then ExtrinsicObjec.objectType contais
> a reference to a Concept I have defined under a BusinessDocument
> (should be CCTS) Concept node. The tree resemble to this:
> 
> ObjectType ClassicationScheme
>  - xml
>   - ebxml
>    - ccts
>     - ABIE
>     - BBIE
>     - ASBIE [1]
>     - ACC
>     - BCC
>     - ASCC  [1]
>     - ACCC  [2]
>     - BCCC  [2]
>     - ASCCC [1] [2]
>     - CCT
>     - DataType [3]
> 
> ** Am I missing some concepts??
> 
> ** Should long names be used for clarity??
> 
> [1] *Not used*!! In my implementation I do not store an Association
> CC/BIE. I simply associate 2 aggregates with 'Contains'. Not needed???
> 
> [2] We used the concept of candidate so that 'our' CoreComponents
> could be somehow replaced by CoreComponents from the catalog.
> 
> [3] Not present in my implementation but I see the need for it now.
> For instance, to store localized enumeration/regexps. BIEs have
> Contexts (Classifications) that could define the region where they
> should be used.. Same CC, different BIE for different region,
> different DataType, but still same CCT.
> 
> And what about Contexts? Do they need a pattern too? I've used RIM's
> Classification mechanism for Contexts so that each Context Category
> has it's own ClassificationScheme.
> 
> *** We've created our contexts even though the spec says that
> contexts should be taken from many different specs/locations..
> 
> Diego
> 
> > -----Original Message-----
> > From: Chiusano Joseph [mailto:chiusano_joseph@bah.com]
> > Sent: Wednesday, June 04, 2003 11:54 PM
> > To: Nikola
> > Cc: regrep-cc-review@lists.oasis-open.org
> > Subject: Re: [regrep-cc-review] Re: Mapping Patterns [was: Kickoff!]
> >
> >
> > Thanks Nicola. That answers the e-mail that I just sent asking you for
> > another mapping pattern.
> >
> > Would you be willing to keep a list of these mapping patterns for us?
> > This will help us create a "RIM binding manual" for other
> > initiatives to
> > use in creating their own RIM bindings (i.e. one step in a mapping
> > scenario would be to define the mapping pattern you need to
> > use based on
> > X available patterns, etc.).
> >
> > Does anyone have any other suggestions for mapping patterns?
> > If not just
> > yet, that's ok - they'll fall out of our future discussions.
> >
> > Joe
> >
> > Nikola wrote:
> > >
> > > <Farrukh>
> > > >Thanks Diego - But how would you capture in the registry that an
> > > >ExtrinsicObject is an ABIE (Aggregate Business Information
> > Entity) vs.
> > > >an ACC (Aggregate Core Component)?
> > > >
> > > By defining a hierarchty within the ObjectType scheme for
> > CCTS maybe.
> > > </Farrukh>
> > >
> > > +1.
> > >
> > > Another pattern -> "ObjectTypeHierarchy"
> > >
> > > Note: I realized that we might want to rename / branch out
> > the thread.
> > >
> > > Nikola
> > >
> > > You may leave a Technical Committee at any time by visiting
> > http://www.oasis-open.org/apps/org/workgroup/regrep-cc-review/
> members/leave_workgroup.php
begin:vcard 
n:Chiusano;Joseph
tel;work:(703) 902-6923
x-mozilla-html:FALSE
url:www.bah.com
org:Booz | Allen | Hamilton;IT Digital Strategies Team
adr:;;8283 Greensboro Drive;McLean;VA;22012;
version:2.1
email;internet:chiusano_joseph@bah.com
title:Senior Consultant
fn:Joseph M. Chiusano
end:vcard


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