[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: DRAFT DATA MODEL
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC