Re: Encapsulating Derivation

I agree that we should substitutability and i wonder should we allow the CE 
to query the parent class list when it encounter a LFB that it don't 
know?Has their any method in protocol draft to do these,thanks.
Yours,Fenggen
>From: "Joel M. Halpern" <[email protected]>
>Reply-To: "Joel M. Halpern" <[email protected]>
>To: [email protected]
>Subject: Encapsulating Derivation
>Date: Wed, 18 Oct 2006 12:02:39 -0400
>
>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

_________________________________________________________________
璐逛杞 MSN Explorer:   http://explorer.msn.com/lccn/