ElementParameters and "collection-type" classes generally

[GoogleCodeExporter]

The term "collection type classes" has worked its way into our discussion and 
metamodel. Apparently,  ElementParameters is one of these collection-type 
classes. I think the notion of a collection-type class should be used 
sparingly, if at all. The metamodel should describe objects in the domain of 
discourse, (which is process analysis, not XML schema).  Every metaclass in 
the model should serve a distinct purpose in the domain of discourse, and the 
text definition should speak to this purpose in the domain. In contrast to 
this, we have something called ElementParameters whose definition is "the 
concrete class definition of all parameter perspectives." What is a "parameter 
perspective" ? Why need ElementParameter be concrete? 

There are 6 object types that are related to ElementParameter through 
composition 0..1. The association is navigable to these 6 metaclasses, yet they 
aren't named. All of the definitions of these 6 types use the word "regroup". 
This looks  like a UML model describing an XML structure.  I'm guessing 
that ElementParameter should be an abstract class with 6 specializations.

Original issue reported on code.google.com by pode...@gmail.com on 30 Mar 2012 at 5:58

[GoogleCodeExporter]

It was decided on the September 20th conference call that we would keep the 
collection types for readability

Original comment by sringue...@trisotech.com on 20 Sep 2012 at 7:45

• Changed state: Fixed

[GoogleCodeExporter]

Original comment by sringue...@trisotech.com on 24 Oct 2012 at 7:04

• Changed state: WontFix