RE: SMIng Requirements: instance identification

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

Comments in-line.

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

I second this.  The requirements simply state (and IMHO should simply state)
that there needs to be a mechanism provided for keying.  How it is done is
out of scope of the requirements and is left to the mapping from the
definition language to the particular implemtation.

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

When I originally came up with this, I did not have a particular example in
mind, but I agree with what you have written.

However, here is a contrived, US-centric example (I will offer apologies in
advance of the example).  Excuse the syntax - it in no way is meant to offer
a syntax for SMIng-defined language, just as an example.

class US_Citizen
{
  key string social_security_number;
  ...
}

Here in Oregon, the DMV (department of motor vehicles) uses my driver's
license number instead of my social security number to uniquely identify me,
so they could have a class (of course this would require that I be a US
citizen to have a driver's license in Oregon, but let's not worry about
that...like I said, the example is contrived):

class Oregon_Driver derives from US_Citizen
{
  boolean is_organ_donor;
  boolean needs_corrective_lenses;
  key string drivers_license_number;
  omit key US_Citizen::social_security_nubmer;
  ...
}

Without the ability to omit keying material derived from the parent class,
the state of Oregon would have to use SSN as a key, when they would rather
just use the driver's license number.  Given some time, I could probably
come up with a better example.

Jamie