RE: DRAFT DATA MODEL

[Paul Denning <pauld@mitre.org>]

At 11:56 AM 2000-09-27 -0400, James Tauber wrote:
>> Each attribute value has zero or more options. Options can be 
>> things like
>> language codes (RFC 2596 ";lang-en") or transfer syntax 
>> changes (RFC 2251
>> ";binary") or presumably other things in the future. (X.500 
>> has a similar
>> feature which provides temporal context for a value - eg a 
>> value is only
>> useful between the hours of 9:00 in the morning and 5:00 in 
>> the afternoon
>> between Monday and Friday, but not in August, etc etc.)
>
>Interesting (the X.500 bit).
>
>How can we generalized this in the information model?

(I'm de-lurking to share some thoughts)

Need a way to describe constraints; i.e., a constraint language.
Need to allow more than one constraint language since everyone will have a favorite, or someone will invent a new and better one.
(Ideas taken from CORBA Notification Service [1], which allows any number of constraint languages, but compliant implementations must support at least the default constraint language defined in the spec.)
Constraint language interpreters could be a plug-in or dynamically-loaded components.

Therefore,

Each entry has zero or more _attributes_ that provide Constraints about that entry.
(Just like RDN is just another _attribute_)
The _attribute type_ of such Constraint _attributes_ shall identify a registered _constraint-language_.
(IANA or some other organization needs to register names of constraint languages)

The _value_ of the constraint _attribute_ shall define the constraint using the _constraint-language_ which corresponds to the _attribute type_

The absence of this constraint _attribute_ implies default constraints

Where are default constraints described?  Do they apply to the entry and all child entries in a hierarchical naming tree?  How to apply default constraints if entries are not hierarchical?  Does the existence of a constraint _attribute_ become the default for child entries?

How about another _attribute_ called a Constraint-Scope _attribute_, where value of constraint-scope must  refer to an existing constraint _attribute_ and a reserved keyword that defines the scope
An _entry_ may have zero or more constraint scope _attributes_.
If an entry has a constraint attribute and no constraint scope attribute, then the default constraint scope is "this-entry-only".
  Exception handling is implementation-specific (e.g., if value of a constraint scope attribute refers to an attribute that does not appear in the entry).

Example:
_attributes_:  X, Y, CX, CY, CZ, CSX, CSW
where
CX, CY, CZ are a constraint attributes
Type of CX could be "OMG-OCL"
Type of CY could be "OMG-PSDL"
The value of CX may refer to X
The value of CY may refer to Y
(That is, the constraint may need to cover or identify other attributes within the entry and their values.  If X="Day-shift" for some entries, and X="Night-shift" for other entries, then CX could have "if X=DayShift, then ..., elseif X=NightShift then ...")
CZ is a constraint attribute that may not refer to any attributes within the entry (e.g., may refer to time of day).
CSX and CSW are Constraint Scope _attributes_
CSX is the Constraint Scope for CX
CSX value may be something like "CX:default-for-children" or "CX:this-entry-only"
CSW may be "CW:default-for-children", but since we have not defined CW, then this would be an exception to be processed in an implementation-specific manner.

[1] http://cgi.omg.org/cgi-bin/doc?formal/00-06-20

Paul