Re: [regrep] Remove RegistryEntry class

[Farrukh Najmi <Farrukh.Najmi@Sun.COM>]

Matthew MacKenze wrote:

> Farrukh,
>
> Agreed.  RegistryEntry was a good idea in uncertain times though.  
> Lets all observe a moment of silence for 
> RegistryEntry.........................OK, done.
>
> :-)

After a sufficient period of respectful mourning in memory of the dear 
departed RegistryEntry class :-) ,
attached is the revised figure 2 for RIM.

Thanks all for your support in getting issues like this resolved quickly
so we can get the specs ready for TC review in early January.

>
> Happy New Year everyone.

All the best.

>
> -Matt
>
>
> Farrukh Najmi wrote:
>
>>
>> As I work my way through regrep-rim-3.0-draft-01 document I see 
>> another area where we
>> have unnecessary complexity that is hard for us to describe to our 
>> intended reader.
>>
>> I am talking about the RegistryEntry class. Much functionality from 
>> this class has bubbled up to RegistryObject class over the years.
>> All this class provides at this point is the expiration and stability 
>> attributes:
>>
>>  <complexType name="RegistryEntryType">
>>    <complexContent>
>>      <extension base="tns:RegistryObjectType">
>>        <attribute name="expiration" type="dateTime" use="optional"/>
>>        <attribute name="stability" type="tns:referenceURI" 
>> use="optional"/>
>>      </extension>
>>    </complexContent>
>>  </complexType>
>>  <element name = "RegistryEntry" type = "tns:RegistryEntryType" 
>> substitutionGroup="tns:Identifiable" />
>>
>> There is little rhyme or reason that we can provide for why some 
>> classes are derived from RegistryEntry and why others are derived
>> from RegistryObject. I propose we simplify the model and remove the 
>> RegistryEntry class all together. We can still define expiration and 
>> stability attributes
>> as canonical Slots on the RegistryObject class so that any object can 
>> have stability and/or expiration defined in a standard way if needed.
>>
>> BTW for what its worth these attributes have not been used much in my 
>> experience with various deoployments of freebXML Registry.
>>
>> I have long felt that the RegistryEntry class is unnecessary and 
>> should be removed. Does anyone have any objections to removing this 
>> additional layer in our model?
>>
>


-- 
Regards,
Farrukh