Re: [higgins-dev] OID and name uniqueness

["Tom Doman" <TDoman@xxxxxxxxxx>]

BTW, I'm curious how eDirectory exposed it's schema through LDAP so I'm going to get an LDIF dump and send it out.  Things like createTimestamp and modifyTimestamp were just part of the eDirectory object model.  We exposed them through LDAP but I don't remember if they were explicitly listed as MUSTs.  In a latter directory project that we never released, they became operational attributes but we were always explicit even with operationals with MUSTs.  In that same project, we actually did create a class for the rootDSE and listed the dSAOperationals as MUSTs on it.  This is all FWIW, because I know there are directory implementations which aren't explicit so we'll have to do something extra anyway.

Tom Doman
Novell Inc.

>>> "Tom Doman" <TDoman@xxxxxxxxxx> 9/22/2006 2:15 PM >>>
Thanks Mark, having your RDF output will be great.  I'm sure we'll have some good dialogue as a result.

Currently, I'm doing nothing with the USAGE attribute on attribute definitions (it's another one of the items on my list).  So, right now, if it's not explicitly listed in the MUSTs (actually just realized I forgot to add these to my internal list ... I'll send out a new sample with this and the other changes I've made recently) or MAYs, it'll have no "rdfs:domain" whatsoever.

Being more of an eDirectory guy than a straight up LDAP guy like Jim, I went to consult RFC2252 to see if I could get definitions on the different USAGE values but I couldn't find them there.  One of the things I wanted to verify was that "directoryOperation" meant that EVERY entry was required to have this attribute maintained.  If so, their "rdfs:domain" could be set to "#top".  Further I wanted to verify that "dSAOperation" meant that these attributes were required to be maintained on the rootDSE (or provided when specified on a search of the rootDSE, how and wherever they are maintained).  If so, perhaps we could make a class to represent the rootDSE and list it as the "rdfs:domain" on each attribute definition of that USAGE.  Anyway, googling hasn't turned up hard definitions for each USAGE value for me to rest solid anything on.  Could you point me to something?

Tom Doman
Novell Inc.

>>> Mark Wahl <mark.wahl@xxxxxxxxxxxxxxxxxxxx> 9/22/2006 12:25 PM >>>
Tom Doman wrote:
> Thanks Mark!  A couple of questions:

> 2. On issue 2, would you suggest then that I prefix the schema 
 > with the server address the schema was mapped from to help
 > mitigate the issue you raise?  e.g.
 > ldap://servername:port#1.3.6.1.4.1.1466...  I'd hate to do that
 > for every server especially when most of the "multiple LDAP servers"
 > share the exact same schema.  I guess we could do some inspection
 > against known or our "preferred" definitions and only tag the ones
 > that differ from that.

Yep, where a schema element's definition matches that of the
standards, using a shorter URI for the OID would make sense.

BTW what do you specify as the 'domain' for an LDAP operational
attribute?

> 3. I've been doing a little reading on your tool schemat on 
 > ldap.com and see that the source code is available there.
 > Do you have an output sample you'd be willing to post or send?

Yes I've been running the (LDIF-style) schema from the LDAPv3 RFCs
through schemat's LDIF-to-OWL converter - still some bugs, but I'll
gather the RDF output files this weekend.

Mark Wahl
Informed Control Inc.
_______________________________________________
higgins-dev mailing list
higgins-dev@xxxxxxxxxxx 
https://dev.eclipse.org/mailman/listinfo/higgins-dev 
_______________________________________________
higgins-dev mailing list
higgins-dev@xxxxxxxxxxx 
https://dev.eclipse.org/mailman/listinfo/higgins-dev