...
| KIM | PSU | Open Registry |
|---|---|---|---|
The Registry shall support a LIFE CYCLE model. Each user is in a specific state; incoming events MAY trigger a transition to a new state; entering a new state MAY trigger sending events. Each of these transitions MAY be associated with a different Business Process. | | | |
The Registry shall support having unique LIFE CYCLE models for each Affiliation type (eg staff accounts are closed immediately on separation; faculty permissions are trimmed on separation but accounts are closed six months after separation). | | | |
The Registry shall support allowing a site to manage the Rules that define the transitions within a LIFE CYCLE. | | | |
The Registry shall support optionally sending events whenever a user's attributes or Affiliation types changes. | | | |
The Registry shall support a core set of information that is maintained about each person (eg name(s), DOB, citizenship, etc). | | | |
The Registry shall optionally support, for each Affiliation type, a scheme that defines the set of information and attributes that will be maintained for this Affiliation type for each user (eg staff have titles and office locations, students do not) | | | |
It shall be easy for sites to modify and extend the schema associated with an Affiliation type (both the data definition step, and adding code to do specialized processing). | | | |
The Registry shall come with scheme sets that could be used with different models of Person Registry (eg thin, medium, fat). | | | |
The Registry shall provide the ability to have people review and approve changes and transitions via a Workflow mechanism. | | | |
...