RE: DRAFT DATA MODEL

[William Aitken <AitkenW@globalknowledge.com>]

James Tauber [JTauber@bowstreet.com] wrote:

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

I think that DSML 1.0 was only addressing entries already existing in a
directory. However, if all LDAP operations including 'add' (creation) are to
be addressed in DSML 2.0, then a tree structure and naming rules concepts
are required because 1) a parent must exist, 2) naming attribute(s)must be
declared, and 3)the RDN of the child must be unique amongst its siblings (if
any).

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

The DN can be thought of as a registration of the unique name of entry in
the DIT namespace. As such uniqueness and not the tree concept is mandatory.
If, however, we are considering the actual creation of the entry (with the
identity of the DN) in the server/DIB, then the tree structure and the rules
for adding leaves to it are mandatory. The DN is the registered 'hook' to
the result of the addition of the leaf (RDN) entry.  

Having said that, can we consider LDAP as an explicitly constrained subset
of (2). 

Am I making sense? It is Friday pm. :-)

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

Yes, I think so. See my comments above.

Bill

-----Original Message-----
From: James Tauber [mailto:JTauber@bowstreet.com]
Sent: Wednesday, September 27, 2000 11:57 AM
To: 'Chris Ridd'; 'dsml@lists.oasis-open.org'
Subject: RE: DRAFT DATA MODEL


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