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