More clarifications

diff --git a/doc/guide/admin/schema.sdf b/doc/guide/admin/schema.sdf
index 6befdd9cbca85c9c6a2e80c97229eea928ccbce8..ef4543be651c908eecd37f5f86972f34a3d31964 100644 (file)
--- a/doc/guide/admin/schema.sdf
+++ b/doc/guide/admin/schema.sdf
@@ -417,39 +417,43 @@ any LDAPv3 server and easily construct directives for use with
 {{slapd}}(8).
 
 LDAPv3 servers publish schema elements in special {{subschema}}
-entries (or subentries).  {{slapd}}(8) publishes a single subschema
-entry normally named {{EX:cn=Subschema}}.  In a server which
-supports a single subschema subentry, the DN of the subschema
-subenty can usually be found by examining the value of the
-{{EX:subschemaSubentry}} attribute type in the {{root DSE}}.
-Other servers may publish multiple subschema entries.  These
-can be located by examining the {{EX:subschemaSubentry}} attribute
-contained in the entry at the root of each administrative context.
+entries (or subentries).  While {{slapd}}(8) publishes a single
+subschema subentry normally named {{EX:cn=Subschema}}, this behavior
+cannot be expected from other servers.  The subschema subentry
+controlling a particular entry can be obtained by examining the
+{{EX:subschemaSubentry}} attribute contained in the entry at the
+root of each administrative context.  For example,
+
+>      ldapsearch -LLL -x -b "dc=example,dc=com" -s base "(objectclass=*)" subschemaSubentry
 
 To obtain the schema from a subschema subentry, you can use
 ldapsearch(1) as follows (replace the search base as needed):
 
 >      ldapsearch -LLL -x -b "cn=Subschema" -s base "(objectclass=subschema)" attributeTypes objectClasses
 
+where "cn=Subschema" is the value of subschemaSubentry returned in
+the prior search.
+
 This will return {{TERM:LDIF}} output containing many type/value
 pairs.  The following is an abbreviated example:
 
 >      dn: cn=Subschema
+>      objectClasses: ( 1.1.2.2.2 NAME 'myPerson' DESC 'my person' SUP inet
+>       OrgPerson MUST ( myUniqueName $ givenName ) MAY myPhoto )
 >      attributeTypes: ( 1.1.2.1.1 NAME 'myUniqueName' DESC 'unique name wi
 >       th my organization' EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubst
 >       ringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 SINGLE-VALUE )
 >      attributeTypes: ( 1.1.2.1.2 NAME 'myPhoto' DESC 'a photo (applicatio
 >       n defined format)' SYNTAX 1.3.6.1.4.1.1466.115.121.1.40
->      objectClasses: ( 1.1.2.2.2 NAME 'myPerson' DESC 'my person' SUP inet
->       OrgPerson MUST ( myUniqueName $ givenName ) MAY myPhoto )
 
 Capture the output of the search in a file and then edit the file:
 
 + to contain only desired type/value pairs
 ^ join LDIF continuation lines
 ^ replace attribute type with directive name
-(e.g. {{EX:s/attributeTypes:/attributeType/}} and
-{{EX:s/objectClasses:/objectClass/}}).
+(e.g. {{EX:s/attributeTypes:/attributeType /}} and
+{{EX:s/objectClasses:/objectClass /}}).
+^ reorder lines so each element is defined before first use
 ^ continue long directives over multiple lines
 
 For the three type/value pairs in our example, the edit should
@@ -470,7 +474,7 @@ result in a file with contains of:
 >              MUST ( myUniqueName $ givenName )
 >              MAY myPhoto )
 
-Save in an appropriately named file (e.g. {{F:my.schema}}).
+Save in an appropriately named file (e.g. {{F:local.schema}}).
 You may now include this file in your {{slapd.conf}}(5) file.
 !endif
 
@@ -478,10 +482,10 @@ You may now include this file in your {{slapd.conf}}(5) file.
 H3: OID Macros
 
 To ease the management and use of OIDs, {{slapd}}(8) supports
-{{Object Identifier}} macros.  The {{EX:objectIdentifier}} is used
-to equate a macro (name) with a OID.  The OID may possibly be derived
-from a previously defined OID macro.   The {{slapd.conf}}(5) syntax
-is:
+{{Object Identifier}} macros.  The {{EX:objectIdentifier}} directive
+is used to equate a macro (name) with a OID.  The OID may possibly
+be derived from a previously defined OID macro.   The {{slapd.conf}}(5)
+syntax is:
 
 E:     objectIdentifier <name> { <oid> | <name>[:<suffix>] }