Re: DRAFT DATA MODEL

[Chris Ridd <chris.ridd@messagingdirect.com>]

James Tauber <JTauber@bowstreet.com> wrote:
> 
> 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.]

This looks basically sound. Specific comments are inline.

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

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

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

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

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

And which attribute types it must have.

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

The syntax definitions and matching rule definitions are also part of the
schema.

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

I'm not quite sure where you're going here! Could you elaborate?

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

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

RFC 2252 hints at this stuff in passing - section 6.11 for DIT Content
Rules, and section 6.33 for DIT Structure Rules.

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

There were efforts several years ago to map OIDs into DNs. I don't recall
what came of it, but presumably it resulted in DNs like:

	<arc=12, arc=4, arc=5, arc=2, ...>

representing the title attribute type.

Cheers,

Chris