Issue 7754: Rule (38) p. 30                                                                                                                                                                                         (mof2idl-ftf)
Source: Vanderbilt University (Mr. Jeff Parsons, j.parsons@vanderbilt.edu)
Nature: Uncategorized Issue
Severity: 
Summary: The CCM component mapping for an Association has the suffix
"Component", unlike any of the the other component mappings
in the document. That's a little puzzling. Also, no details
are given about the corresponding home mapping. How is its
type name derived? Does it have the same factory operations as
the other CCM home mappings in the document?

Resolution: 
Revised Text: Resolution:
This issue was a follow up of issue #7681 and is discussed and resolved in conjunction with that issue.

Resolution of issue #7681 also resolves this issue.


Actions taken:
August 27, 2004: received issue
August 1, 2005: closed issue
Discussion: 

End of Annotations:=====
ule (38) p. 30


The CCM component mapping for an Association has the suffix
"Component", unlike any of the the other component mappings
in the document. That's a little puzzling. Also, no details
are given about the corresponding home mapping. How is its
type name derived? Does it have the same factory operations as
the other CCM home mappings in the document?



thanks,


 Rule (38) p. 30
> 
> The CCM component mapping for an Association has the suffix
> "Component", unlike any of the the other component mappings
> in the document. That's a little puzzling. Also, no details
> are given about the corresponding home mapping. How is its
> type name derived? Does it have the same factory operations as
> the other CCM home mappings in the document?
> 


As the example on page 31 shows, the component is managed by a home
interface named according to the assocation-name with the postfix "Home".
But you are right: the corresponding rule to produce that interface is
missing. Basically, the home interface is only needed if we have to navigate
from a package to its contents (cp. Rules 40/41 on page 33). IMHO, we should
change the spec to be able to directly navigate to an association's derived
component. Since the lifecycle of the component is determined by the
outermost package's component (implicit creation) we need no factory
operations and therefore in principle no home interface. That results from
the fact that the components derived for an association are rather the
M2-level "representative" (in the repository) than a M1-level instance. I
think we need to consistently adjust the spec regarding this issue.


What is your opinion on this topic??


Regards,
Jeff Parsons