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


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


Happy New Year everyone.


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?

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