RE: DRAFT DATA MODEL

[William Aitken <AitkenW@globalknowledge.com>]

Chris Ridd [mailto:chris.ridd@messagingdirect.com] wrote:

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

This was addressed in ITU-T X.660 (Naming, Addressing and Registration)
Amendment 1 (10/96) "Incorporation of object identifiers components" which
defined oidRoot object class (oid:2.17.2.3) a subclass of 'Alias'; oidC1
attribute (oid:2.17.2.0); oidC2 attribute (oid:2.17.2.1); oidC attribute
(oid:2.17.2.2); oidRootNf name form (oid:2.17.2.4). An example in LDAP form
would be: 

  dn: oidC=840 + oidC2=16 + oidC1=2 ;represents <joint.country.US>

  dn: oidC=113730,oidC=1,oidC=840 + oidC2=16 + oidC1=2
;represents<joint.country.US.org.Netscape> 

  dn: oidC=12,oidC=4 + oidC2=5 + oidC1=2   ;represents <title attribute:
2.5.4.12>
	
  dn: oidC=0,oidC=2 + oidC2=17 + oidC1=2 	 ;represents <oidRoot object
class: 2.17.2.3>

Bill
 
-
William Aitken
mailto:William.Aitken@globalknowledge.com
+1-613-736-6108 x151  fax +1-613-736-6105
Enterprise Directories: Consulting and Training
http://db.globalknowledge.com/catalog/catcourse.asp?cat=36
http://www.globalknowledge.com
Global Knowledge Network 
2430 Don Reid Drive
Ottawa, ON  
Canada K1H 1E1




-----Original Message-----
From: Chris Ridd [mailto:chris.ridd@messagingdirect.com]
Sent: Wednesday, September 27, 2000 5:40 AM
To: James Tauber; 'dsml@lists.oasis-open.org'
Subject: Re: DRAFT DATA MODEL


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