Subject: Questions on schema inheritance and naming

From: [email-masked]
Date: Thu, 12 Aug 1999 12:13:26 +0100

Hello

I am new to the policy arena as well as LDAP and modelling in general.
However after looking through the drafts for the core policy schema and the
qos extensions (draft-snir-policy-qos-infomodel-00.txt) I couldn't help
thinking that some of the classes are superflous. The inheritance vs
composition argument?

For example there is policyGroup, qosPolicyRepository, qosPolicyDomains,
qosPolicyDomain and qosNamedPolicyContainer. These all appear to be
basically the same thing to me. Namely a structural class which is used as a
container and or a place to attach auxiliary classes. The only real
difference that I can see is the name. But shouldn't that just be an
attribute value? One single class ie policyGroup could be used for all of
these. Albeit with a name change, maybe policyContainer ?

The only new attributes that are defined in the subclasses are user friendly
names. Therefore why not add a user friendly naming attribute (friendlyName
or perhaps just name) to the policy class, then the policyGroupName,
qosDomainName, adminDomainName etc attributes can be dispensed with.

If required the policyKeywords attribute could be used to distinguish
between the types of data held inside the container. So if an ldap client
wants to retrieve all the policy domains it can use the appropriate keyword
in the search filter.

Like I said above I'm new to modelling, so if my thinking is all wrong then
please educate me!

I also found the naming of some of the classes and attributes a little
strange. As a software developer I believe that descriptive names are very
important. For example the name policyInstance would suggest to me one
complete instance of a policy ie everything that comprises one complete
policy. But in the core model it is used as a structural class to attach
policyCondition or policyRule auxiliary classes. It represents a part or
component of a policy and not the whole thing as the name would suggest.

Another example is qosNamedPolicyContainer, the definition of which states:
quote
This class represents an administrative policy rule container.
unquote

followed by
quote
The "namedQosPolicyContainer" fills the fole of a diff-serv "Role" object.
unquote

Therefore I would expect the class name to more accurately reflect what the
class is / does.

Some of the auxiliary class names end with "AuxClass" but others don't, why?
It would be nice to have a more consistant naming strategy.

On another note, I haven't noticed any discussion on any actual
implementations of these schema or attempts to write ldap clients to access
them. Or have I missed something somewhere. As this is basically what I'll
be doing over the next few weeks I would be interested to hear of other
peoples experiences on this.

Vince Suttle
Network Management Research
British Telecommunications Plc
BT Advanced Communications Technology Centre
Adastral Park
Marlesham Heath
Ipswich
UK
[email-masked]
+44 (0)1473 605458

---

From: "Ryan Moats" <[email-masked]>
Date: Thu, 12 Aug 1999 08:24:31 -0500

Vince-

| Hello
|
| I am new to the policy arena as well as LDAP and modelling in general.
| However after looking through the drafts for the core policy
| schema and the qos extensions (draft-snir-policy-qos-infomodel-00.txt) I
couldn't help
| thinking that some of the classes are superflous. The inheritance vs
| composition argument?
|
| For example there is policyGroup, qosPolicyRepository, qosPolicyDomains,
| qosPolicyDomain and qosNamedPolicyContainer. These all appear to be
| basically the same thing to me. Namely a structural class which
| is used as a container and or a place to attach auxiliary classes. The
only real
| difference that I can see is the name. But shouldn't that just be an
| attribute value? One single class ie policyGroup could be used for all of
| these. Albeit with a name change, maybe policyContainer ?

| The only new attributes that are defined in the subclasses are
| user friendly names. Therefore why not add a user friendly naming
attribute
| (friendlyName or perhaps just name) to the policy class, then the
policyGroupName,
| qosDomainName, adminDomainName etc attributes can be dispensed with.

As I remember it, there is already an attribute name that is being
inherited.
A reason for having extra attributes (IMHO) is so that you can have
RDNs that look reasonable.  See below for more details...

| I also found the naming of some of the classes and attributes a little
| strange. As a software developer I believe that descriptive names are very
| important. For example the name policyInstance would suggest to me one
| complete instance of a policy ie everything that comprises one complete
| policy. But in the core model it is used as a structural class to attach
| policyCondition or policyRule auxiliary classes. It represents a part or
| component of a policy and not the whole thing as the name would suggest.
|
| Another example is qosNamedPolicyContainer, the definition of
| which states: 'This class represents an administrative policy rule
container.'
|
| followed by 'The "namedQosPolicyContainer" fills the fole of a diff-serv
"Role" object.'
|
| Therefore I would expect the class name to more accurately reflect what
the
| class is / does.
|
| Some of the auxiliary class names end with "AuxClass" but others
| don't, why? It would be nice to have a more consistant naming strategy.

Actually, they all should.  We are currently discussing the
ABNF for the LDAP schema on the mailing list, which includes
some class naming changes.  The ball on this is currently in
my court and I'll be answering sometime in the near future.
The discussion is captured in the archives, so you should look
there to come up to speed on it.

| On another note, I haven't noticed any discussion on any actual
| implementations of these schema or attempts to write ldap clients
| to access them. Or have I missed something somewhere. As this is basically
what I'll
| be doing over the next few weeks I would be interested to hear of other
| peoples experiences on this.

I would be a little patient in implementation still.  The LDAP schema
drafts do not follow the requirements of an LDAP schema (specifically
no ABNF).  Once this gets nailed down and a new draft issued, then
I think some implementation experience might not be a bad idea.

Ryan Moats
[email-masked]