Encapsulating Derivation

Weiming raised an interesting idea for derivation.  I would really 
appreciate comments from other folks.  And I have had two thoughts 
since his note.  Questions at the bottom for the group.

First, to recapitulate his suggestion (Please, correct me if I get it 
wrong).  Given an LFB Class A, and and LFB Class B that is being 
derived from A, the derivation element in the definition of B becomes
     <derivedFrom elementID="1">A</derivedFrom>
(Where the "1" could be any number, but would typically be 1 for 
obvious reasons.)
Then, relative to an instance of LFB class B, if one wanted to refer 
to a component defined with path P in LFB Class A, one would use the path 1.P.
This avoids issues of identifier collision, and makes parent 
references explicit.


I realized that there is one use of derivation that we had supported 
that this would prohibit.
Suppose we have a structure defined:
    Y = <struct> some elements </struct>
and an LFB class using that structure
    A = <LFBClass>
                 <element elementID="3">
                    <name>X</name>
                    <type>Y</type>
                  </element>
                  other elements
         </LFBClass>
Now suppose that an extended structure Z is defined based on Y
    Z = <struct>
              <derviedFrom>Y</derivedFrom>
              extra stuff
         </struct>
(That much can be done with encapsulating derivation as well.  The 
derivedFrom would have an element ID.)
Currently, we permit the definition of a new LFB Class B derived from 
A, where the element X, with the same id, is extended to use the structure Z:
    B = <LFBClass>
               <derivedFrom>A</derivedFrom>
                 <element elementID="3">
                    <name>X</name>
                    <type>Z</type>
                  </element>
               other additional elements
           </LFBClass>

With encapsulating derivation that is not permited.  Encapsulating 
derivation only permits extension at the top level of the LFB Class 
or structure being defined.
This may be a tradeoff we are willing to make (giving up those forms 
of derivation).  But we should do so explicitly


I also realized that we are not achieving the original goal of the 
derivation with what we have right now.  One of the goals of allowing 
derivation was substitutability.  That is, if an FE had instances of 
a class the CE didn't understand, the CE could treat them as being of 
their parent class.
Currently, the primary value in derivation is to avoid 
redeclaration.  For example, the attrribute properties all deerive 
from a common parent so that they share certain elements in common 
ways, making definition and processing easier and reducing the 
chances of leaving something out.
We could add substitutability into the system.
The FE would need to report, in the FE Object list of supported LFB 
classes, the parent class chain for all the classes.  (If we decide 
to do this, it will report it as a tree, from the top down, to avoid 
duplication of information.)
The CE would then note any classes it did not know, and treat them as 
synonyms for the lowest parent it does know.
The CE would still have to be careful to use the correct class ID to 
reference the elements, since instance IDs are only unique within a class.
This can be supported with either derivation mechanism.  With the 
current mechanism, it just works.
If we want to support substitutability with the encapsulating 
derivation technique, then the parentage reporting would simply have 
to have the prefixing element ID at each level, so as to permit the 
CE to transparently construct the right ids.


So, the questions:
Do we want to switch to encapsulating derivation?
Do we want to extend the Support LFB Class reporting to support 
substitutability?

Thank you,
Joel M. Halpern