Issue 4622: Restrictions needed for nested Packages and Classes (mof-rtf)
Source: DSTC (Dr. Stephen Crawley, nobody)
Nature: Uncategorized Issue
Severity: 
Summary: In recent MOF RTF telcon discussions, we tentatively concluded that we need 
Constraints on the MOF Model to forbid 1) clustering of nested Packages,
2) inheritance of nested Packages and 3) clustering of Classes.

Additional Text:

There are three arguments for the proposed restrictions.  The first
argument is that supporting inheritance / clustering in these cases adds
to the complexity of MOF implementations.  Since practical metamodels
never seem to use these combinations of features, it is hard justify
supporting them.

The second argument is that clustering and inheritance of nested
Packages is problematical.  The elements of a nested Package are
implicitly defined in the context of the nested Package's outer Package.
A Constraint or Operation defined on / within a nested Package may
reasonably refer to Associations or "all_of_*" collections in the
enclosing context.   When a nested Package is inherited or clustered
outside of the context of its parent Package, the Constraint and
Operation semantics may cease to be meaningful.

The second argument does not apply to a nested Package that is 
inherited by another nested Package with the same outermost Package.
However, we have not been able to identify a use case for this sort
of thing.  Hence the first argument applies.

The third argument is that the MOF IDL mapping explicitly excludes all
of these cases; see "Section 5.5 - Preconditions for IDL Generation".

Resolution: 
Revised Text: 
Actions taken:
October 18, 2001: received issue
Discussion: 

End of Annotations:=====
X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4
To: issues@omg.org
cc: mof-rtf@omg.org
Subject: Restrictions needed for nested Packages and Classes
Mime-Version: 1.0
Date: Thu, 18 Oct 2001 15:05:17 +1000
From: Stephen Crawley <crawley@dstc.edu.au>
X-Scanned-By: MIMEDefang 1.0
(http://www.roaringpenguin.com/mimedefang/)
Content-Type: text/plain; charset=us-ascii
X-UIDL: 3'&!!f/o!!p4G!!h;nd9


Summary: 

In recent MOF RTF telcon discussions, we tentatively concluded that we
need 
Constraints on the MOF Model to forbid 1) clustering of nested
Packages,
2) inheritance of nested Packages and 3) clustering of Classes.

Additional Text:

There are three arguments for the proposed restrictions.  The first
argument is that supporting inheritance / clustering in these cases
adds
to the complexity of MOF implementations.  Since practical metamodels
never seem to use these combinations of features, it is hard justify
supporting them.

The second argument is that clustering and inheritance of nested
Packages is problematical.  The elements of a nested Package are
implicitly defined in the context of the nested Package's outer
Package.
A Constraint or Operation defined on / within a nested Package may
reasonably refer to Associations or "all_of_*" collections in the
enclosing context.   When a nested Package is inherited or clustered
outside of the context of its parent Package, the Constraint and
Operation semantics may cease to be meaningful.

The second argument does not apply to a nested Package that is 
inherited by another nested Package with the same outermost Package.
However, we have not been able to identify a use case for this sort
of thing.  Hence the first argument applies.

The third argument is that the MOF IDL mapping explicitly excludes all
of these cases; see "Section 5.5 - Preconditions for IDL Generation".

-- Steve


X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4
To: mof-rtf@omg.org
Subject: Re: Issue 4622: Restrictions needed for nested Packages and
Classes 
Mime-Version: 1.0
Date: Thu, 25 Oct 2001 15:01:45 +1000
From: Stephen Crawley <crawley@dstc.edu.au>
X-Scanned-By: MIMEDefang 1.0
(http://www.roaringpenguin.com/mimedefang/)
Content-Type: text/plain; charset=us-ascii
X-UIDL: UJ9e9LBA!!V^ed9`3!e9


Folks,

Here's a draft resolution for this issue.  My memory is a bit vague
about whether we decided to allow nested Packages to inherit or be
imported by other Packages.  If yes, do we intend the current IDL 
mapping preconditions to still apply?

-- Steve


> Source: DSTC (Dr. Stephen Crawley, crawley@dstc.edu.au)
> Nature: Uncategorized Issue
> Severity: 
> Summary: In recent MOF RTF telcon discussions, we tentatively
> concluded that 
> we need Constraints on the MOF Model to forbid 1) clustering of
> nested
> Packages, 2) inheritance of nested Packages and 3) clustering of
> Classes. 
>
> Additional Text: There are three arguments for the proposed
> restrictions. 
> The first argument is that supporting inheritance / clustering in
> these 
> cases adds to the complexity of MOF implementations. Since practical 
> metamodels never seem to use these combinations of features, it is
> hard 
> justify supporting them. 
> 
> The second argument is that clustering and inheritance of nested
> Packages 
> is problematical. The elements of a nested Package are implicitly
> defined 
> in the context of the nested Package's outer Package. A Constraint
> or 
> Operation defined on / within a nested Package may reasonably refer
> to 
> Associations or "all_of_*" collections in the enclosing
> context. When a 
> nested Package is inherited or clustered outside of the context of
> its 
> parent Package, the Constraint and Operation semantics may cease to
> be 
> meaningful. The second argument does not apply to a nested Package
> that 
> is inherited by another nested Package with the same outermost
> Package. 
> However, we have not been able to identify a use case for this sort 
> of thing. Hence the first argument applies. 
> 
> The third argument is that the MOF IDL mapping explicitly excludes
> all of
> these cases; see "Section 5.5 - Preconditions for IDL Generation". 

Proposed Resolution:

Add Constraints to the MOF Model to make these restrictions, and
remove
the relevant bullet points in section 5.5. 

Proposed Revised Text:

[CAUTION: the text changes partly overlap changes from Issue 4202!!!]

Change Section 3.4.23 as follows:

  replace bullet points 2 & 3 with the following:

    * A Package may inherit from other non-nested Packages via the
      Generalizes association.
    * A Package may import another Package or Class via an Import
      and the Aliases association.
    * A Package may cluster another non-nested Package via an Import
      and the Aliases association.

  add the following to the Constraints subsection:

    [nested Packages cannot be inherited [C-YY+2]]

  add the following to the IDL subsection (after the last "const
  string"):

    const string CANNOT_INHERIT_NESTED_PACKAGES =
      "org.omg.mof:constraint.model.package.cannot_inherit_nested_packages";

Change Section 3.4.24 as follows:

  replace the first 2 paragraphs with the following:

    An Import is used to represent one of two forms of Package
    composition,
    depending on the "isClustered" attribute.  An Import is contained
    by
    a Package, and is related to some other Package or Class via the
    Aliases Association.

    An Import with "isClustered" equal to false indicates that the
    containing
    Package imports the related Namespace.  Importing a Namespace
    makes 
    the ModelElements declared in the imported Namespace visible in
    the
    importing Namespace; see Section 4.7.3.  The name of the Import
    (if 
    different from the name of the imported Namespace) is a local
    alias 
    for the import.  The meaning of the "visibility" attribute is
    currently
    unspecified.

    An Import with "isClustered" equal to true indicates that the
    containing
    Package clusters the related Namespace.  In this case, both the
    clustering
    and clustered Namespaces must be un-nested Packages. Furthermore
    the
    clustered Package cannot be abstract.  Clustering effects
    visibility
    and allows aliasing in the same way as importing (see above).  In
    addition, it makes the "extent" of the clustering Package contain
    the "extent" of the clustered Package; see Section 4.7.4.
    
  add the following to the Constraints subsection:

    [Only Packages may be clustered [C-YY]]
    [Nested Packages cannot be clustered [C-YY+1]]

  add the following to the IDL subsection (after the last "const
  string"):

    const string CAN_ONLY_CLUSTER_PACKAGES =
      "org.omg.mof:constraint.model.package.can_only_cluster_packages";

    const string CANNOT_CLUSTER_NESTED_PACKAGES =
      "org.omg.mof:constraint.model.package.cannot_cluster_nested_packages";


Add the following Constraints to Section 3.9.4 (at end):

  [C-YY] CanOnlyClusterPackages
  ...
  evaluation policy: immediate
  description: Only Packages may be clustered.
  context: Import
    self.isClustered implies self.imported.oclIsTypeOf(Package)

  [C-YY+1] CannotClusterNestedPackages
  ...
  evaluation policy: deferred
  description: Nested Packages cannot be clustered.
  context: Import
    (self.isClustered && self.imported -> oclIsTypeOf(Package))
  implies
      self.imported.container -> size = 0

  [C-YY+2] CannotInheritNestedPackages
  ...
  evaluation policy: immediate
  description: nested Packages cannot be inherited
  context: Package
    self.supertypes -> forAll(s | s.container -> size = 0)

Change Section 5.5 as follows:

  change bullet 6 to read:

    *  A nested Package may not be used as a supertype. ([C-YY+2]
       precludes
       a nested Packages from being used as a subtype.)

  change bullet 7 to read:

    *  A nested Package may not be imported by another Package. 
       ([C-49] precludes a nested Package from importing another
       Package.)
       nested Packages from being subtypes.)