Re: SMIng Requirements: instance identification

["Hillel D. Nissenbaum" <hillel@alum.poly.edu>]

I've been listening in on the conversations and thought I'ld throw my thoughts in for whatever they are worth:

•   If I understand Andrea correctly there is a requirement for a "key" keyword in the language, but the semantics bound to that keyword are left to the model(s). I don't really see how useful this is except that it avoids adding on model variant ways of specifiying which attributes have something to do with an objects unique identifier.  Although I suspect each model would have to go to sufficient lengths in defining how naming is done, especially with regard to using a naming heirarchy as discussed, that having a common keyword may not get much.

•   Jamie Jason's desire "for there to be some way when defining classes in the  language that is derived from the requirments to indicate that an attribute in  the class should be unique across all instances of the  class" is clearly contrary to the definition of the "key" requirement, if this is an agreed to requirement it is a separate one. Call it "unique" or something similar.

•   As far as breaking inheritance is concerned; I think we have to recognize that object naming is distinct from polymorphism otherwise even adding a "key" attribute to a subclass would break inheritance. Otherwise I can't see how it is possible to define a model indendent language that includes inheritance.  As I see it the OO behavior of "what I can do with A I can do with its subclass B" has to be true once you are given an object instance (or a reference to one), finding that object reference using a unique name is outside of the objects attributes and behavior.  Although perhaps a base class (or even the root class) of a particular model could have a getName() method which would know how to produce an object's name from all appropriate keys.

•   An unrelated thought on the requirements prompted by others mentioning GDMO and CIM is as follows.  I understand this document is intended as the requirements for SMIng, but would it make sense for the working group to determine if any existing languages meet the requirements? Without doing any kind of analysis it seems like CIM's MOF (Managed Object Format) would meet these requirements.  I can't help but think it would be nice to avoid adding another management modeling language to my repertoire.  This got me thinking about a previous thread regarding the languages' name perhaps YAMMS would be appropriate ( Yet Another Management Modeling Syntax ) which would open us up to a whole vegetable garden of clever related terms :^)

Henry D. Nissenbaum 
ISSANNI Communications

------Original Message------
From: "Andrea Westerinen" <andreaw@cisco.com>
To: "Weiss, Walter" <wweiss@ellacoya.com>, <sming@ops.ietf.org>
Sent: March 2, 2001 12:59:28 AM GMT
Subject: RE: SMIng Requirements:  instance identification


RE: SMIng Requirements: instance identificationHaving a "key" keyword is
part of the language.  Having a naming algorithm or specific properties as
keys is part of the model.  IMHO.

Andrea
-----Original Message-----
From: owner-sming@ops.ietf.org [mailto:owner-sming@ops.ietf.org]On Behalf Of
Weiss, Walter
Sent: Thursday, March 01, 2001 8:35 AM
To: sming@ops.ietf.org
Subject: RE: SMIng Requirements: instance identification


Back when this was a NIM requirement, we wanted to stay away from keying
because previous experience demonstarted how much a particular keying
strategy influenced the overall model and how severly it undermined specific
mappings. At this point I can't say that avoiding the keying semantics makes
mappings easier. I also can't say that a specific keying strategy maps
better to various data models.

In the end, these requirements need to reflect two points of consensus:
1. Is keying part of the model/language or is it part of the mapping?
2. If it is part of the model, what keying approach lends itself to the
broadest possible set of mappings?

regards,

-Wal!
ter

-----Original Message-----
From: Andrea Westerinen [mailto:andreaw@cisco.com]
Sent: Wednesday, February 28, 2001 5:28 PM
To: Robert Moore; sming@ops.ietf.org
Subject: RE: SMIng Requirements: instance identification


Let me take a stab at a reply and the other authors can jump in ...

1. Being able to specify a property as a key (an OID, a
string, etc.) is
different than specifying a naming hierarchy, or the
semantics of "how to"
create the key.  The SMIng requirements state that a
mechanism should be
provided to define a property as a key.  That's it.  This is purely
language.  How the key is defined/implemented/... is up to
the model.  Also,
the section about associations (Section 9) clearly states
that the ability
to specify "containment!
 for scoping and naming" is needed
(first paragraph).
Now containment may not be appropriate in all models - but
the semantics are
needed for a general data modeling language.

2. I viewed "un-keying" not as breaking inheritance (since
the property is
still inherited), but as saying "what works in the superclass
as a unique
identifier does not work for me."  I would hope that this is
not used very
often, and expected it to generate some discussion :-).  I
would like to get
Jamie to provide a use case/example - since this was his section.

Andrea

-----Original Message-----
From: owner-sming@ops.ietf.org [mailto:owner-sming@ops.ietf.org]On
Behalf Of Robert Moore
Sent: Wednesday, February 28, 2001 12:57 PM
To: sming@ops.ietf.org
Subject: SMIng Requirements: instance identification


I have what I think are two independent concerns with
the discussion of instance identification in the -00
SMIng Requirements draft:

1. The document appears to rule out from the beginning
   the possibility of having SMIng use the kind of
   hierarchical naming used by X.500, LDAP, and CMIP.
   By requiring that each instance contain all the key
   attributes necessary to identify the instance
   uniquely, don't you rule out an approach where
   instances contain just enough information to
   have uniqueness within the scope of a superior,
   which in turn contains just enough information to
   have uniqueness within the scope of *its* superior,
   and so on?

   If this is intentional, that is, if the goal is to
   state as a requirement on SMIng that it SHALL NOT
   use hierarchical instance naming, then I think you!

   need more argument for why this should be included
   as a requirement.

2. In the last paragraph on page 6 and the first
   paragraph on page 7, the idea is introduced of
   "un-keying" in a subclass an attribute that was
   identified as a key attribute in a superclass.
   This runs counter to at least my OO intuitions; in
   fact, it sounds like a vestige of the "partial
   inheritance" idea that was mentioned earlier, but
   (I think) withdrawn.  Do the authors have some
   specific case in mind, that's driving the inclusion
   of this "un-keying" as a requirement?  If so,
   maybe the WG can come up with a better way to
   handle this case.

Regards,
Bob

Bob Moore
IBM Networking Software
+1-919-254-4436
remoore@us.ibm.com

______________________________________________
FREE Personalized Email at Mail.com
Sign up at http://www.mail.com/?sr=signup

---

Having a "key" keyword is part of the language.  Having a naming algorithm or specific properties as keys is part of the model.  IMHO.

 

Andrea

-----Original Message-----
From: owner-sming@ops.ietf.org [mailto:owner-sming@ops.ietf.org]On Behalf Of Weiss, Walter
Sent: Thursday, March 01, 2001 8:35 AM
To: sming@ops.ietf.org
Subject: RE: SMIng Requirements: instance identification

Back when this was a NIM requirement, we wanted to stay away from keying because previous experience demonstarted how much a particular keying strategy influenced the overall model and how severly it undermined specific mappings. At this point I can't say that avoiding the keying semantics makes mappings easier. I also can't say that a specific keying strategy maps better to various data models.

In the end, these requirements need to reflect two points of consensus:
1. Is keying part of the model/language or is it part of the mapping?
2. If it is part of the model, what keying approach lends itself to the broadest possible set of mappings?

regards,

-Walter

> -----Original Message-----
> From: Andrea Westerinen [mailto:andreaw@cisco.com]
> Sent: Wednesday, February 28, 2001 5:28 PM
> To: Robert Moore; sming@ops.ietf.org
> Subject: RE: SMIng Requirements: instance identification
>
>
> Let me take a stab at a reply and the other authors can jump in ...
>
> 1. Being able to specify a property as a key (an OID, a
> string, etc.) is
> different than specifying a naming hierarchy, or the
> semantics of "how to"
> create the key.  The SMIng requirements state that a
> mechanism should be
> provided to define a property as a key.  That's it.  This is purely
> language.  How the key is defined/implemented/... is up to
> the model.  Also,
> the section about associations (Section 9) clearly states
> that the ability
> to specify "containment for scoping and naming" is needed
> (first paragraph).
> Now containment may not be appropriate in all models - but
> the semantics are
> needed for a general data modeling language.
>
> 2. I viewed "un-keying" not as breaking inheritance (since
> the property is
> still inherited), but as saying "what works in the superclass
> as a unique
> identifier does not work for me."  I would hope that this is
> not used very
> often, and expected it to generate some discussion :-).  I
> would like to get
> Jamie to provide a use case/example - since this was his section.
>
> Andrea
>
> -----Original Message-----
> From: owner-sming@ops.ietf.org [mailto:owner-sming@ops.ietf.org]On
> Behalf Of Robert Moore
> Sent: Wednesday, February 28, 2001 12:57 PM
> To: sming@ops.ietf.org
> Subject: SMIng Requirements: instance identification
>
>
> I have what I think are two independent concerns with
> the discussion of instance identification in the -00
> SMIng Requirements draft:
>
> 1. The document appears to rule out from the beginning
>    the possibility of having SMIng use the kind of
>    hierarchical naming used by X.500, LDAP, and CMIP.
>    By requiring that each instance contain all the key
>    attributes necessary to identify the instance
>    uniquely, don't you rule out an approach where
>    instances contain just enough information to
>    have uniqueness within the scope of a superior,
>    which in turn contains just enough information to
>    have uniqueness within the scope of *its* superior,
>    and so on?
>
>    If this is intentional, that is, if the goal is to
>    state as a requirement on SMIng that it SHALL NOT
>    use hierarchical instance naming, then I think you
>    need more argument for why this should be included
>    as a requirement.
>
> 2. In the last paragraph on page 6 and the first
>    paragraph on page 7, the idea is introduced of
>    "un-keying" in a subclass an attribute that was
>    identified as a key attribute in a superclass.
>    This runs counter to at least my OO intuitions; in
>    fact, it sounds like a vestige of the "partial
>    inheritance" idea that was mentioned earlier, but
>    (I think) withdrawn.  Do the authors have some
>    specific case in mind, that's driving the inclusion
>    of this "un-keying" as a requirement?  If so,
>    maybe the WG can come up with a better way to
>    handle this case.
>
> Regards,
> Bob
>
> Bob Moore
> IBM Networking Software
> +1-919-254-4436
> remoore@us.ibm.com
>
>
>
>
>

Attachment1.html

Content-Type:	text/html
Content-Encoding:	quoted-printable