OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

regrep message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: Re: [regrep] Remove RegistryEntry class

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?


GIF image

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]