Re: PCLS classes deprecated in PCELS

Ryan as just nicely explained this to me in a way that got it through my 
thick skull.  You both are correct.  We can not move existing classes.

Hence, one needs to create new classes, and include text that says "use 
this instead of the old thing".

Unfortunate, but really a common problem with class naming / inheritance 
(not specific to just LDAP).

As I said to Ryan, thanks for the patience explaining this.
Joel

At 12:39 PM 9/12/2003 -0500, Larry S. Bartz wrote:
>Ryan Moats wrote, On 09/12/03 11:27:
>[snip}
>>Actually, that is a solution for all of the subclass cases: in PCELS call 
>>tem pcime*, give them different OIDs from what's in PCLS and then everything
>>is ok.
>
>I'll go further and suggest that every component of PCIMe which is
>not exactly as defined in PCLS should be prefixed "pcime". If PCELS
>simply avoids deprecating, renaming, or redefining anything from
>PCLS, there can be no conflict with PCLS. And if everything new
>which is introduced by PCELS is prefixed "pcime", there can be no
>confusion about which is "core" and which is "extension".
>
>Such a strategy will ultimately satisfy Joel's concerns, when he wrote:
> > My feeling is that concerns about PCELS should be in the context of
> > support for PCIMe,
>and
> > if one can accurately map PCIMe to LDAP in a way that is compatible
> > with PCLS, then that would clearly seem desirable
>
>PCELS should map PCIMe to LDAP in a way which is not INcompatible with
>PCLS, in a way which does not break PCLS. I agree that "concerns about
>PCELS should be in the context of support for PCIMe". I augment that
>by saying that PCELS should not be concerned with recasting PCLS in
>any way.
>
>PCELS should focus on mapping PCIMe to LDAP. PCELS should avoid any
>impact on PCLS.
>
>
>--
>--
>#::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::|
># Larry Bartz
>#
>#  voice (317) 226-7060
>#  FAX   (317) 226-6378
>#::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::|