RE: DRAFT DATA MODEL

[James Tauber <JTauber@bowstreet.com>]

> > DSML 2.0 DATA MODEL [INITIAL DRAFT 2000-09-26]
> [...]
> > [something about naming context??]
> 
> They're administrative features of the servers themselves, 
> not really part of the information (data) model.

Okay. We can drop it.

Should we call this an information model rather than a data model?

> > Each _attribute type_ has a _name_ and a unique identifier. [3]
> 
> Actually zero or more names. Yes, names are optional :-) The object
> identifier is required.

Good. Makes sense.

> > The _attribute type_ constrains:
> >	 - how many values for that attribute an entry may have
> >	 - syntax to which the values must conform
> >	 - matching rules
> >	 - other??
> 
> Each attribute also has one or more values (:-) which need describing.

Yep.

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

> > [1] my understanding is that the tree structure of a DIT is 
> an artifact of
> > the DN being a concatenation of RDNs and not an inherent 
> property of the
> > entries. I can see a number of advantages in not assuming, 
> in the data
> > model, that the entries are in a tree. what do people think?
> 
> I'm not quite sure where you're going here! Could you elaborate?

If you look at DSML 1.0, there is no tree structure other than that implicit
in the DNs.

As I see it there are two approaches that can be taken:

	(1) treat the tree structure as derived from the DN
	(2) treat the DN as derived from the tree structure

The advantage of the former is that is allows us to deal with directory-like
entries that are uniquely identified but not hierarchically without losing
any capabilities of DSML for dealing with entries where they *are*
hierarchical.

> Your data model makes the assumption of a tree structure, in 
> that RDNs of entries must be unique amongst siblings.

Right, I put that in but I'd like to relax it in the information model to
make it (slightly) broader.

> The structure of a DIT is defined by directory structure rules, which
> involve a name form (what attributes must be used in RDNs) 
> and a structural
> object class. Entry contents are themselves defined by 
> directory content
> rules (rules over and above what the object classes define.)

Hmm. Does the information model need to include these rules?

James