Re: Families of Entries

["Mark D. Anderson" <mda@discerning.com>]

>I have produced an example in the X.500 PDAM text.

That being the F510PDAMv12 document you posted a reference to before?

>> Apparently the family members don't have individual DN's; 

>Sorry, they do. They are entries.

>>I have to address the whole family as a DN, and identify a
>>particular child with a filter? Or what?

>Either the ID is not clear enough, or you have not read it properly.

Probably a bit of both, plus my own inexperience.
I think I made the assumption that children were somehow
not "real" entries because of the intro's reference to "subentries",
and because the protocol section ("3. Protocol Support for Families")
discusses just those family extensions exclusively.
In never saw it stated explicitly that child entries are plain-old-entries
also, and all the normal LDAP operations work on them just fine.

>> Could there be an automatic emulation (or whatever) of the language
>> parameter, the one parameter that LDAP already supports (AFAIK)?

>Sorry, I dont follow this question

I can currently specify different values for a single attribute for "lang-en" 
and for "lang-fr". As such, language is currently a special-cased 
parameter ("child entry") in ldap.

>> Generally, properties are only attached to the whole complex object
>> ("pref", "home", etc.)? That is where things get a little confusing -- the
>> semantics of the family hierarchy could either be containment or metadata.

>Containment I would say. Metadata is used to control the family 
>hierarchy (as it is the rest of the DIT)

Sorry, I meant a different kind of "metadata" (properties). My point is that 
your single mechanism is used both for constituent parts ("city", "zip")
and for properties ("home", "work"). I don't think this is necessarilly
bad; I'm just trying to clarify.

-mda