[Date Prev][Date Next]
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/