Issue 2186:  Need for light-weight References (mof-rtf)
Source:  (, )
Nature:  Revision
Severity:  Significant
Summary: Summary: A requirement possibly exists for a light-weight version of
 References (or something like them), which at the M1 level does not
 require the existence of Attribute instance objects and the associated
 heavy weight querying mechanisms.
 
 

Resolution: 
Revised Text: 
Actions taken:
November 6, 1998: received issue
July 23, 1999: Deferred:MOF 2.0
Discussion: 
Possible solutions:
1. No change. Is the requirement met by allowing Class values Attributes with aggre-gation==
none/composite semantics? How about Attributes that have an aggrega-tion
attribute?
2. Define the Association with visibility==private. This "works" for the IDL mapping,
because no IDL would get generated. However in Java for example, declaring the
corresponding Association class as "private" does not eliminate the need for it. So
unless a (hypothetical) mapping to Java did something odd-ball for Associations
with visibility==private, the heavy-weight query mechanisms may still be used; e.g.
in Constraint evaluation.
3. Add a "is_hidden" Attribute to Association that allows the modeller to specify that
querying interfaces are not required. [A server may choose to build references on
top of queries, but that is an implementation issue.] Possible solutions: 

No change. 
Redefine the Model constraints and the IDL mapping such that an Association with visibility==private or protected can be referenced, but that it will have no Association IDL. 
Add a "is_hidden" Attribute to Association that allows the modeller to specify that querying interfaces are not required. [A server may choose to build references on top of queries, but that is an implementation issue.] 
Define a Tag (e.g. "org.omg.mof.idl_lightweight" or "org.omg.mof.idl_suppress") that tells the IDL mapping to leave out the Association's IDL interface. 
The first (non-)solution is not acceptable. This issue perceived to be a serious problem. 
The second solution "works" in the context of the IDL mapping. However, consider a mapping to Java ... where a visibility is orthogonal to suppression of implementation machinery.  The danger is that by co-opting Model::Association::visibility to mean that an interface is to be suppressed in the IDL context, we risk causing future problems in other contexts. 

The third solution involves an unnecessary change to the MOF Model. 

The fourth solution doesn't seem to have any significant disadvantages.  It might also be worth generalizing this to allow suppressing of IDL elements for Classes, Attributes, Operations and so on.  For instance, by suppressing an Attribute, you might remove individual set/get operations, limiting access / update to a (hypothetical) "get_all_attributes" or via "ref_*" operations. 


End of Annotations:=====
Return-Path: <crawley@dstc.edu.au>
X-Exmh-Isig-CompType: unknown
X-Exmh-Isig-Folder: inbox
To: mof-rtf@omg.org, issues@omg.org
Subject: Need for light-weight References
Errors-to: request@omg.org
Date: Fri, 06 Nov 1998 16:18:11 +1000
From: Stephen Crawley <crawley@dstc.edu.au>


["new issue 16" from Seattle RTF doc.]

Source: DSTC (Dr. Stephen Crawley, crawley@dstc.edu.au)
Nature: Editorial
Severity: Significant
Summary: A requirement possibly exists for a light-weight version of
References (or something like them), which at the M1 level does not
require the existence of Attribute instance objects and the associated
heavy weight querying mechanisms.

Additional text:

First, this suggestion is argueably out of scope for the RTF.

Possible solutions:

1) No change. Is the requirement adequately met by allowing Class
values Attributes with aggregation==none/composite semantics? How
about Attributes that have an aggregation attribute?

2) Define the Association with visibility==private. This "works" for
the IDL mapping, because no IDL would get generated. However in Java
for example, declaring the corresponding Association class as
"private" does not eliminate the need for it. So unless a
(hypothetical) mapping to Java did something odd-ball for Associations
with visibility==private, the heavy- weight query mechanisms may still
be used; e.g. in Constraint evaluation.

3) Add a "is_hidden" Attribute to Association that allows the modeller
to specify that querying interfaces are not required. A server may may
internally implement references on top of queries, but that is not our
concern.  [This analogous to a feature of DSTC's initial proposal that
was dropped in the merger.]