RE: PCLS classes deprecated in PCELS

John,

Thanks for the detailed comments and suggestions. This is greatly
appreciated. As already noted, there will be a PCELS revision shortly. This
revision will take into account the suggestions that you and the other
participants made on the list.

There are a few clarifications that I'd like to ask for. See below in
<mircea>..</mircea>.


-----Original Message-----
From: John Strassner [mailto:[email protected]]
Sent: Monday, September 15, 2003 9:15 AM
To: Pana, Mircea; 'Joel M. Halpern'; Larry S. Bartz; '[email protected]'
Cc: [email protected]; David McTavish
Subject: RE: [Policy] PCLS classes deprecated in PCELS


With respect to your first point, PCELS does NOT already do this everywhere
- for example, there are cases where you've changed the name of the PCLS
class but kept the names of its attributes. That's very bad and will result
in some NASTY errors. 

<mircea>
Can you please give an example from the current PCELS? I don't understand
what you mean by "changed the name of the PCLS class". Except for pcimGroup*
and the PCLS classes marked as deprecated (that will be changed as noted)
there are concepts that have been redefined (i.e. new classes introduced by
PCELS with new OIDs). Some use attributes defined by PCLS. Do you see
anything wrong with that?</mircea>

With respect to the second point, that's much better. I will provide
comments on the schema itself next week.

With respect to naming, I don't understand the problem. You have build a new
design, not an update of an existing design. Thus, new concepts should be
assigned a new prefix (and I'd prefer pcels, instead of pcime) whereas
existing concepts should be assigned the pcim prefix. Thus, it is not a
"everything or nothing" decision but instead a judicious application of new
(pcels) vs old (pcim) concepts.

<mircea>
I have heard valid arguments for using a different naming prefix in PCELS
than the one used by PCLS. These arguments are based on the view that
PCIM/PCLS is the "core" while PCIMe/PCELS is an "extension". This is one
point of view. Mine is that PCIM/PCLS alone is incomplete and that only
*together* with PCIMe/PCELS it provides THE Framework for the development of
domain specific submodels. Both produced by the same WG btw. (I'm not going
to argue that though - it seems to be a sore spot!) For me, the naming
prefix is a minor issue and I can live with a different prefix if people are
so strongly against reuse.

Thanks,
Mircea.
</mircea>

regards,
John

John C. Strassner
Chief Strategy Officer
Intelliden Inc.
90 South Cascade Avenue
Colorado Springs, CO  80906  USA
phone:  +1.791.785.0648
  fax:     +1.719.785.0644
email:    [email protected]

-----Original Message-----
From: Pana, Mircea [mailto:[email protected]] 
Sent: Friday, September 12, 2003 3:11 PM
To: 'Joel M. Halpern'; Larry S. Bartz; '[email protected]'
Cc: [email protected]; David McTavish
Subject: RE: [Policy] PCLS classes deprecated in PCELS

So, if I understand correctly, everything would be "OK" if PCELS did: 
1. Define only subclasses of PCLS classes and, where not possible, redefine
PCLS concepts as new classes (use different names and oid.s). This is
already the case in the currently published ID with the exception of
pcimGroup* that would need to be redefined with a different name.  
2. Use "for compliance with PCIMe implementations SHALL use <list schema
items> instead of <list of schema items> for the realization of <concepts>"
instead of deprecating PCLS classes. This would be added to a new revision
of the ID.
I'm fine with both. (I hope I did not miss anything) 
Wrt. naming PCELS classes and attributes pcime* instead of pcim*, as long as
there are no naming conflicts, I would prefer to avoid it if possible. Could
you live with that? However if we have to do it for one item we should do it
for all.
Thanks, 
Mircea. 



> -----Original Message----- 
> From: Joel M. Halpern [mailto:[email protected]] 
> Sent: Friday, September 12, 2003 1:50 PM 
> To: Larry S. Bartz; '[email protected]' 
> Cc: [email protected]; David McTavish; Pana, Mircea 
> Subject: Re: [Policy] 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 
> >#:::::::::::::::::::::::::::::::::::::::::::::::::::::::::::: 
> ::::::::::| 
> 
> 
> 
> _______________________________________________ 
> Policy mailing list 
> [email protected] 
> https://www1.ietf.org/mailman/listinfo/policy 
>