Re: Feedback Due 9/5: Updated Requirements Mapping

["Chiusano Joseph" <chiusano_joseph@bah.com>]

Forwarded on behalf of Diego. Please see comments marked with <JMC>.
Thanks for your feedback Diego!

The issues: (JMC: REPRODUCED HERE FROM BELOW WITH RESPONSES)
-----------


D1. More details about Slots mechanism:
[S3,S7,S10,S20,S22,S24,S26,S27,S32,S34,S44,S48]
Slot mechanism: define slotName and slotType. Example:
Slot.slotName="Business Term"
Slot.slotType="String"

<JMC>
Yes - that's a great reminder that we need names/types for all Slots,
for our Technical Note. If you'd like to provide suggestions for other
Slots as well, that would be great (if you have time).
</JMC>

D2. More details about Association mechanism:
[S5,S12,S29,S30,S50]
Association: define sourceObject, targetObject and associationType.
Association.sourceObject: parent ACC
Association.targetObject: contained BCC/ACC
Association.associationType: "Contains"

<JMC>
Yes - we'll also need this information for our Technical Note. Thanks
for giving us a head start on it.
</JMC>

D3. Association CC/BIE:
[S5,S6,S13,S14,S17,S18]
IMHO, we should not cut ASCC support. We're not doing it, are
we? 

<JMC>
Not at all - reference [S2]: "Association Core Components will be
represented as Associations between ACCs, and will not be considered as
"first rate" Core Components".  
</JMC>

If I have ASCC and I want to store them in the registry
can I still choose our mapping approach?? I hope so. I though
the point was to use RIM Association to represent it. 

<JMC>
Yes - see above.
</JMC>

I propose again (if that is not what we're doing already!) that we store
ASCC as RIM Association, use Association.name/Association.
description/Association's Slots to store CC/CCProperty details,
just like we do for BCC. 

<JMC>
Not sure what you mean by "to store CC/CCProperty details". An ASCC
Association will serve to associate 2 ACCs, and nothing more. CC
Properties will not be represented as entities in our architecture.
</JMC>

What was the problem with that???

[S49,S50,S51]
ASBIE issue, same as ASCC. Map all fields to RIM Association
fields/Slots.

<JMC>
Yes - same general handling as ASCC; an ASBIE will be represented as an
Association connecting 2 ABIEs (see [S47]).
</JMC>

D4. I18n Terms:
[S7,S10,S22,S26]
Open issue: Object Class Term - map to RegistryObject.name?
IMHO, the fact that we can't localize Slots is a big issue
on current RIM. I have need to express these term in Finnish
and that would cut off the English terms.. in that sense
RegistryObject.name would suit, because it is I18n enable.
Now, RegistryObject.name has only 1 name. If we store Object
Class Term there (and do the same for all other term in their
corressponding objects), where do we store
DictionaryEntryName???

<JMC>
Good point - I think we should use a Slot for Object Class Term, rather
than RegistryObject.name. I am also going to raise the I18N issue to the
Registry TC for the full TC to handle.
</JMC>

D5. Basis mechanism:
[S46,S47]
How do we know that a CC is basis for a BIE? Is there a
Slot in the BIE?? Or an Association? Either case, define it.

<JMC>
Yes - this is vaguely defined in [S45]: "Business Information Entities
are created by taking existing Core Components and classifying them
according to one of the 8 Context Categories". More details will be
provided in our Technical Note (i.e. how each ClassificationNode of a
context category has Slots that contain the "BBIE Property Term
Qualifier" and "ABIE Object Term Qualifier" values that are
automatically placed in the "Property Term Qualifier" and "Object Term
Qualifier" Slots (respectively) when a BIE is created from a CC, etc.).
</JMC>

D6. Contexts and Classifications:
[S42]
Classification Scheme hierarchy is already defined by RIM.
You have a "root" ClassificationScheme that contains 0 or
more ClassificationNode(s), which can recursivelly contain
0 or more ClassificationNode(s). ClassificationNode has a
field for parent. No need for Association here.

<JMC>
Yes - great point. Since this is covered by our existing architecture,
we will leave it out of our Technical Note (being careful to cover only
those things required for Core Components in our Technical Note).
</JMC>


Diego Ballvé wrote:
> 
> Joe and team,
> 
> First of all, my apologies for being inactive in this work for
> the last couple of weeks. Unfortunatelly I haven't got the Oasis
> membership I was promised. I'm still trying to get it through
> Republica but we are under heavy restructuring in the company
> and people seem to be too busy.. at least I've learned I should
> not promise forward what has been promised to me.
> 
> Next, lets work. Joe, I kindly ask you to forward this mail and
> other mails to listserv. I've gone through our mappings doc and
> identified some issues we might still be facing. I don't want to
> delay this work so lets be fast to solve them if they're really
> issues. I'll be available for mail discussion until later hours
> this week (I'mat GMT+2).
> 
> Two comments about the issues listed below:
> - I'll double check the requirement numbers once we agreed we
> should do something about an issue.
> - Feel free to answer the issues one by one.
> 
> Best regards,
> Diego
> 
> --------------------------------------------
> Diego Ballve
> Product Manager
> Republica Corp., Products
> Survontie 9, 40500 Jyväskylä, Finland
> E-mail: diego.ballve@republica.fi
> http://www.republica.fi/
> http://www.x-fetch.com/
> --------------------------------------------
> 
> The issues:
> -----------
> 
> D1. More details about Slots mechanism:
> [S3,S7,S10,S20,S22,S24,S26,S27,S32,S34,S44,S48]
> Slot mechanism: define slotName and slotType. Example:
> Slot.slotName="Business Term"
> Slot.slotType="String"
> 
> D2. More details about Association mechanism:
> [S5,S12,S29,S30,S50]
> Association: define sourceObject, targetObject and associationType.
> Association.sourceObject: parent ACC
> Association.targetObject: contained BCC/ACC
> Association.associationType: "Contains"
> 
> D3. Association CC/BIE:
> [S5,S6,S13,S14,S17,S18]
> IMHO, we should not cut ASCC support. We're not doing it, are
> we? If I have ASCC and I want to store them in the registry
> can I still choose our mapping approach?? I hope so. I though
> the point was to use RIM Association to represent it. I propose
> again (if that is not what we're doing already!) that we store
> ASCC as RIM Association, use Association.name/Association.
> description/Association's Slots to store CC/CCProperty details,
> just like we do for BCC. What was the problem with that???
> [S49,S50,S51]
> ASBIE issue, same as ASCC. Map all fields to RIM Association
> fields/Slots.
> 
> D4. I18n Terms:
> [S7,S10,S22,S26]
> Open issue: Object Class Term - map to RegistryObject.name?
> IMHO, the fact that we can't localize Slots is a big issue
> on current RIM. I have need to express these term in Finnish
> and that would cut off the English terms.. in that sense
> RegistryObject.name would suit, because it is I18n enable.
> Now, RegistryObject.name has only 1 name. If we store Object
> Class Term there (and do the same for all other term in their
> corressponding objects), where do we store
> DictionaryEntryName???
> 
> D5. Basis mechanism:
> [S46,S47]
> How do we know that a CC is basis for a BIE? Is there a
> Slot in the BIE?? Or an Association? Either case, define it.
> 
> D6. Contexts and Classifications:
> [S42]
> Classification Scheme hierarchy is already defined by RIM.
> You have a "root" ClassificationScheme that contains 0 or
> more ClassificationNode(s), which can recursivelly contain
> 0 or more ClassificationNode(s). ClassificationNode has a
> field for parent. No need for Association here.
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