RE: SMIng Requirements: instance identification

["Jason, Jamie" <jamie.jason@intel.com>]

Title: RE: SMIng Requirements: instance identification

What I would like to see is 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.

 

Maybe the mistake I made was calling a key...that is up for debate.

 

If it turns out that it is more appropriate for individual mappings to determine how they will deal with such a beast, then I am fine with moving it out of the requirements draft and replacing it with verbage that says mapping MUST deal with the issues presented.  For example, what is done in a derived class when there are attributes that are marked as "unique" or "key" (or whatever) in base class(es).

 

Jamie

-----Original Message-----
From: Andrea Westerinen [mailto:andreaw@cisco.com]
Sent: Thursday, March 01, 2001 4:59 PM
To: Weiss, Walter; sming@ops.ietf.org
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
>
>
>
>
>