[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: objectClass in entry attribute order

Michael Ströder wrote:
Dave Horsfall wrote:
On Wed, 14 Feb 2007, Donn Cave wrote:
I don't that I have ever seen objectClass appear anywhere but at the top of the entry, before this. Evidently it isn't a serious problem - these entries are still retrievable, modifiable and slapadd works on them.
Order doesn't matter, but current behaviour seems to be first in first
out or something, thus when you modify an attribute it propagates to the end
of the list.

Additionally any client or server implementation relying on some kind of attribute order or attribute value order is broken. And the order in the LDIF does not necessarily say anything about the order in the internal representation or the order in the LDAPResult message.

Yeah, it looks funny, but end users aren't supposed to "see" raw LDIF.

Yupp. No problem at all if the clients are not broken.

This all comes down to knowing the specs. The X.500 data model defines an "entry" as a SET of attributes. A set is a well-defined mathematical concept; the two key properties here are that there is no ordering of a set's members, and an element can only appear once in a set. Thus, the ordering of attributes in an entry is essentially random, and an attribute can only appear once in an entry.

Likewise an "attribute" is defined as a SET of values. Once again, no ordering, and any value can only appear once in an attribute.

When you know the underlying definitions, everything else is obvious. When you try to use LDAP without knowing the underlying definitions, you tend to get yourself into trouble.
-- Howard Chu
Chief Architect, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc
Chief Architect, OpenLDAP http://www.openldap.org/project/