PSS — PSS storage model and associated object interactions unclear

See the Persistent State Service specification, orbos/99-07-07, section
5.2.2 (or thereabouts) and section 7.

I am confused by the storage model "overview" given in section 5.2.2 and
the more comprehensive treatment in the discussion of the PSDL grammar
in section 7. The treatment of abstract storage types, homes, and their
(concrete) implementations is inadequately mapped between the two,
leading to very unclear semantics. My specific concerns:

• It is explicitly stated in the text that types, homes, and their
  independent derivation lines are taken from a Java model. Why this
  explicit dependence on Java? Could the submitters not come up with a
  more generic model? Has anyone tried to map these concepts to
  Smalltalk, which doesn't have the same kinds of object representation
  and implementation difficulties as Java and C++? Even though I am a
  Smalltalk expert, my attempts at such a mapping on the proposed model
  have been less than exciting.

• Although the keyword "abstract" was already defined, why are abstract
  storagetypes and storagehomes "abstract"? They certainly seem
  concrete enough to me, since I would expect that the definition is
  sufficient to generate code equivalent to a valuetype. This
  ambiguates both the general IDL concept of abstraction and concrete
  storagetypes in particular: in all other places abstract types
  represent non-instantiable objects that have no explicit state, and
  it is not at all clear how concrete storagetypes are more "concrete"
  than their abstract relatives.

• The text indicates that each storagetype must have its own home. Is
  that abstract types, concrete types, or both? Why? Whatever
  happened to polymorphism? If I have multiple storagetypes with
  similar or compatible keying properties, why cannot they all be
  indexed or managed together? I should only require a different home
  if the behavior is different. Even if a language mapping [read that
  as "implementation"] should require such, please don't make that a
  general limitation of the entire model. This is a very useful
  service; let's not restrict its utility or expressive power by
  playing to language limitations.

• I can understand that you want to keep factory, finder, and
  management behavior separate from storage object behavior, but has
  anyone actually articulated the reasons behind this? (This also
  affects the component model.) What are they? I can see several
  reasons for keeping the factory and finder operations with the
  storagetype, in the same way valuetypes specify factory operations.
  I am also concerned about the apparently artificial complexity
  introduced by requiring parallel derivations of storagetypes and
  storagehomes. Why not generate the homes automatically when needed?
• Why are keys placed on the storagehome? It would seem more logical
  that you define the keys (as properties) of the storagetype and then
  optionally map those to indices in a datastore, catalog, or
  storagehome. Perhaps we should indicate that, for a particular
  storagetype, certain state members may participate in a key. Why
  isn't at least one key identified as a primary key? Why cannot I
  explicitly define some keys as unique leaving others as non-unique to
  form inverted indices?
• The text indicates that a concrete storagetype "implements" one or
  more abstract storagetypes. What does this mean? How is this
  accomplished? What are the navigation paradigms, especially for
  multiple storagetypes? What interfaces are expected? This whole
  concept is too weakly specified, and the example in section 10 is too
  simple to explain multiple type implementation.
• What is the purpose of a catalog and its limitation of singleton
  instances of storagehomes? I can think of reasons why I would want
  multiple instances of a particular storagehome, especially for
  configuration management in the datastores. Can one have multiple
  catalogs, and if so, how do you select one of them, since "by name"
  might not be the best keying property?

rejected