RE: response to comments on PCELS-05/May 06

John,

You have started this thread by asking: "why is there no =
pcelsRuleValidityAssociation subclass?" In a subsequent message, you =
have further detailed the issue by saying: "Looking at your class =
structure, since you subclassed other associations, I was surprised that =
you didn't subclass this one as well."

Besides, PCELS defines the pcelsConditionAssociation and =
pcelsActionAssociation classes by subclassing PCLS classes for the =
purpose of extending their semantics. Neither you nor any other reviewer =
of the I-D has expressed any issue with those definitions.

The latest proposal *does* accommodate your original request but I see =
you bringing up a different issue now. So, if you think that it is wrong =
to subclass the PCLS association class(es), please help me out by =
pointing to the LDAP (or other) specification that would be violated. I =
am not aware of any.

Thank you,
Mircea.


> -----Original Message-----
> From: John Strassner [mailto:[email protected]]
> Sent: Friday, June 04, 2004 5:45 PM
> To: Pana, Mircea; [email protected]
> Cc: [email protected]; [email protected]
> Subject: RE: response to comments on PCELS-05/May 06
>=20
>=20
> Hmm.
>=20
> First, I don't think subclassing helps, because the root=20
> problem is that
> pcimRuleValidityAssociation doesn't apply to a pcelsRule=20
> (pcelsRule is a
> sibling of pcimRule. Thus, I believe that you need a new class.
>=20
> Second, rather than pcelsValidityAssociation, could I suggest
> pcelsRuleValidityAssociation?
>=20
> regards,
> John Strassner
> TeleManagement Forum Advisory Director
>=20
>=20
> John Strassner=20
> Chief Strategy Officer=20
> Intelliden Inc.=20
> 90 South Cascade Avenue=20
> Colorado Springs, CO  80906  USA=20
> phone:  +1.719.785.0648=20
>   fax:     +1.719.785.0644=20
> email:    [email protected]
>=20
>=20
>=20
> > -----Original Message-----
> > From: Pana, Mircea [mailto:[email protected]]=20
> > Sent: Friday, June 04, 2004 2:48 PM
> > To: [email protected]; John Strassner
> > Cc: [email protected]; [email protected]
> > Subject: RE: response to comments on PCELS-05/May 06
> >=20
> >=20
> > To accomodate the change requested by Joel, I'm making the=20
> > proposal below. Please review it and let me know as soon as=20
> > possible whether you like or not.
> >=20
> > Instead of re-using pcimRuleValidityAssociation, PCELS would=20
> > introduce a new class: pcelsValidityAssociation. This new=20
> > class would be a subclass of pcimRuleValidityAssociation and=20
> > it would not introduce any new attributes. Its instances=20
> > would be subordinated to pcelsRule instances. (Much like=20
> > pcelsConditionAssociation etc.) The pcelsRule class, instead=20
> > of reusing the pcimRuleValidityPeriodList attribute, would=20
> > use a new attribute (pcelsValidityPeriodList) as reference to=20
> > its pcelsValidityAssociation instances.
> >=20
> > In addition, Note 1 in section 5.4 would be removed.
> >=20
> > Regards,
> > Mircea.
> >=20
> >=20
> > -----Original Message-----
> > From: Joel M. Halpern [mailto:[email protected]]
> > Sent: Friday, June 04, 2004 9:37 AM
> > To: [email protected]
> > Cc: [email protected]; John Strassner; Pana, Mircea
> > Subject: RE: response to comments on PCELS-05/May 06
> >=20
> >=20
> > I have looked this over again, and I think I understand the=20
> question.
> >=20
> > From an object mapping and class definition perspective, it=20
> > appears to me that extending the definition of=20
> > pcimRuleValidityAssociation to point to a pcelsRule is=20
> > probably not appropriate.
> >=20
> > It seems to me thinking about this that adding a different=20
> > association class for the pcelsRule - time-period=20
> > relationship will not adversely affect either existim PCLS=20
> > implementors or future PCELS implementors.  Ruding churn in=20
> > an I-D before publication is not a good reason to avoid=20
> > making a technically correct change.
> >=20
> > However, I could easily have missed multiple aspects of this.=20
> > If there are folks looking at implementing PCELS who have an=20
> > opinion on the complexity of either the current "extension"=20
> > or the proposed additional class, please speak up. If there=20
> > are LDAP folks (other than John, who has been very helpful)=20
> > who can shed light or opinions on this, I would love to hear=20
> > from them.
> >=20
> > Given how many times we have been around the block on this, I=20
> > would like to ask folks to respond within one week.  If we=20
> > hear nothing, I will ask Mircea and company if they can make=20
> > this one last change, and hand the document to Bert for publication.
> >=20
> > And then we will officially close the working group!
> >=20
> > Yours,
> > Joel M. Halpern
> >=20
> > At 07:55 PM 6/3/2004 -0600, John Strassner wrote:
> >=20
> > Subject: RE: response to comments on PCELS-05/May 06
> > To: "Pana, Mircea" <[email protected]>
> > Cc: <[email protected]>,
> >         <[email protected]>,
> >         <[email protected]>
> >=20
> > Hi Mircea,
> > =20
> > thanks for your thoughtful response.
> > =20
> > Regarding the first issue, I still disagree. The definition=20
> > of the class doesn't allow this, even though the semantics=20
> > remain unchanged. Since we are at an impasse, I'm happy to=20
> > let Joel rule one way or the other.
> > =20
> > Regarding changing the note in section 5.4, I agree with the change.
> > =20
> > Regarding the DIT containment issue, I'm happy with your suggestion.
> > =20
> >=20
> > regards,
> > John Strassner=20
> > -----Original Message-----=20
> > From: Pana, Mircea [mailto:[email protected]]=20
> > Sent: Friday, May 28, 2004 8:16 AM=20
> > To: John Strassner=20
> > Cc: [email protected]; [email protected]; [email protected]=20
> > Subject: RE: response to comments on PCELS-05/May 06
> >=20
> >=20
> > Look for my responses in <mircea4></mircea4>. Sorry, I'm slow=20
> > to respond as well.=20
> > Regards,=20
> > Mircea.=20
>=20