DRAFT DATA MODEL

[James Tauber <JTauber@bowstreet.com>]

Here is a first pass at data model in crude point form. Note that there are
requirements made of LDAPv3 directories that I don't think should be
requirements on this data model and, in fact, there are a small number of
LDAP characteristics, noted in footnotes, that I'd like not to enforce in
the data model because I'd really like to generalize the model just enough
to cover RDF [the principal reason being that I'd like DSML to be *the*
XML-based way of querying and modifying not only LDAP directories but
directory-like systems that are really close to LDAP. There aren't people
that are already putting DSML interfaces on relational data. I don't want to
allow that in general, but if the relational data resembles the data model
here, I want to be able to allow DSML to be the query and modification
framework.]

DSML 2.0 DATA MODEL [INITIAL DRAFT 2000-09-26]

A _directory_ is made up of _entries_.

The _entries_ are organized in a tree structure [1]

An _entry_ is made up of a number of _attributes_.

One or more _attribute_ values from the entry form its _relative
distinguished name_ (RDN), which MUST be unique among all its siblings. [2]

Every _entry_ has a unique identifier called its _distinguished name_ (DN)
which is the concatenation of the RDNs from the entry to a child of the root
of the tree.

[something about naming context??]

Each attribute has a _type_.

Each _attribute type_ has a _name_ and a unique identifier. [3]

The _attribute type_ constrains:
	- how many values for that attribute an entry may have
	- syntax to which the values must conform
	- matching rules
	- other??

One _attribute type_ indicates the _object class_ or classes of the entry.
This _attribute_ is required. [4]

The _object classes_ of an entry determine which _attribute types_ it may
take.

The collection of _attribute type definitions_ and _object class
definitions_ is called a _schema_

[_operational attributes_ are of course allowed by the data model but are
not special from the point of view of the data  model]

[the four attributes required by LDAPv3 to be present in all subschema
entries are not part of this data model but fit in to the data model]

Footnotes:
[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?

[2] RDF just gives each resource a unique identifier, ie it has the notion
of a DN but not an RDN. (There is nothing to stop you having an RDN
attribute or attributes in RDF it's just the semantics aren't there in RDF
itself)

[3] In LDAP, entries are uniquely identified by DNs and attribute types are
uniquely identified by OIDs. In RDF, attribute types are just a kind of
entry and are therefore uniquely identified the same way as any other entry,
namely via a URI. I have seen a proposal for OIDs and URIs that we should
look at and probably incorporate. What about DNs as URIs? For directories to
play the XML world, identifiers really have to be URIs. Fortunately it is
relatively easy to grandfather other identification schemes into URIs.

[4] In RDF, the type isn't required.