Re: RIM Issue: Association duplication and usage

[Yutaka Yoshida <Yutaka.Yoshida@eng.sun.com>]

Len,

Thanks for capturing this.
In the last conf. call, we agreed to insert packagedBy
association type and delete 'bidirectional stuffs' from
association methods. However, as for the 'bidirectional stuffs,
if there's no strong objection I'd like to keep the methods as
they are now. I'm completely aware of the issues, but I'm rather
inclined to have a redundancy than losing something at this
critical moment.

yutaka yoshida
Sun Microsystems

 > Date: Mon, 09 Apr 2001 09:04:34 -0400
 > From: Len Gallagher <LGallagher@nist.gov>
 > 
 > 
 > ebXML,
 > 
 > During last Friday's ebXML Regrep conference call, I agreed to raise a RIM
 > issue that we discussed but didn't have an immediate solution for. We
 > agreed it should be put on the Phase 2 Issues List.
 > 
 > In Section 10.1.1 (line 627-631, pages 28-29) RIM (version 0.60)
 > pre-defines the following Association Types:
 > 
 >   RelatedTo
 > 
 >   Packages
 > 
 >   ExternallyLinks and ExternallyIdentifies
 > 
 >   ContainedBy and Contains
 > 
 >   Extends
 > 
 >   Implements
 > 
 >   InstanceOf
 > 
 >   SupercededBy and Supercedes
 > 
 >   UsedBy and Uses
 > 
 >   ReplacedBy and Replaces
 > 
 > The issue is that, for the obvious pairs of association types, it is not
 > clear if one or both of the associations should become instances of the
 > Association class. The result is that a user is never sure which
 > associationType to query for when trying to find all instances of a given
 > source or target. Or if a user specifies one type of association for
 > insertion or deletion, does the implementation automatically enter or
 > delete the inverse instance.
 > 
 > One solution would be to define only 1-way associations so that a user
 > would know that the object being searched for is always a "Source" or a
 > "Target" of a given Association instance. This solution may or may not be
 > sufficient for the un-paired associations given above, e.g. RelatedTo.
 > 
 > Another issue to address at the same time is the privilege issue of who can
 > create new associations. A temporary solution is to require that both the
 > source and target objects of an association be owned by the Submitting
 > Organization, but that has obvious drawbacks. A better solution is to
 > specifiy ownership privilege rules so that others cannot insert new members
 > into a package you own, or others cannot submit a new object to replace an
 > object that you own, etc. 
 > 
 > Another issue to address at the same time is "specializations" among the
 > association types themselves. For example, is "Extends" a specialization of
 > "Uses"? Or, is there a specialization relationship between "Packages" and
 > "Contains"?
 > 
 > 
 > **************************************************************
 > Len Gallagher                             LGallagher@nist.gov
 > NIST                                      Work: 301-975-3251
 > Bldg 820  Room 562                        Home: 301-424-1928
 > Gaithersburg, MD 20899-8970 USA           Fax: 301-948-6213
 > **************************************************************
 > 
 > ------------------------------------------------------------------
 > To unsubscribe from this elist send a message with the single word
 > "unsubscribe" in the body to: ebxml-regrep-request@lists.ebxml.org