RE: SMIng Requirements: instance identification

["Robert Moore" <remoore@us.ibm.com>]

This is still not making sense to me.  If you
require a "key" keyword on properties in a class
definition, then aren't you doing two things:

 - Requiring that all the properties needed to
   provide unique instance identification for an
   instance be so flagged?  Think about the classes
   several weak associations down from the top in
   a CIM model.  These classes typically have a
   lot of key properties, because their propagated
   keys are included as well as their native keys.

   In a hierarchical naming model like GDMO or
   X.500/LDAP, such classes don't need to have
   all these attributes.  All the class itself
   needs (for naming) is enough attributes to
   provide uniqueness within the scope of a
   superior.  So doesn't the SMIng approach to
   instance identification *force* the inclusion
   of extra properties/attributes in class
   definitions, solely for instance identification?

 - Introducing the requirement that all instances
   of a class be identified in the same way?  This
   is different from the approach in GDMO and in
   X.500/LDAP.  With GDMO, for example, a class
   can defined with several attributes that are
   "suitable for naming".  Later, one or more
   NAME-BINDING templates can be defined,
   specifying (1) a superior class under which an
   instance of the subject class can be named, and
   (2) the specific attribute to be used for
   naming it in that context.  X.500/LDAP has
   essentially the same capability.

So I don't agree that mandating that class keys be
identified in class definitions is just a benign
language feature in the SMIng requirements.  Doing
this will introduce real limitations in how naming
can be done in the mapped models.

Regards,
Bob

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



"Andrea Westerinen" <andreaw@cisco.com>@ops.ietf.org on 03/01/2001 07:59:28
PM

Sent by:  owner-sming@ops.ietf.org


To:   "Weiss, Walter" <wweiss@ellacoya.com>, <sming@ops.ietf.org>
cc:
Subject:  RE: SMIng Requirements:  instance identification




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
>
>
>
>
>