Re: objectClass in entry attribute order

[Howard Chu <hyc@symas.com>]

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/