<?xml version="1.0" encoding="UTF-8"?>
<!--
 ! CDDL HEADER START
 !
 ! The contents of this file are subject to the terms of the
 ! Common Development and Distribution License, Version 1.0 only
 ! (the "License").  You may not use this file except in compliance
 ! with the License.
 !
 ! You can obtain a copy of the license at
 ! trunk/opends/resource/legal-notices/OpenDS.LICENSE
 ! or https://OpenDS.dev.java.net/OpenDS.LICENSE.
 ! See the License for the specific language governing permissions
 ! and limitations under the License.
 !
 ! When distributing Covered Code, include this CDDL HEADER in each
 ! file and include the License file at
 ! trunk/opends/resource/legal-notices/OpenDS.LICENSE.  If applicable,
 ! add the following below this CDDL HEADER, with the fields enclosed
 ! by brackets "[]" replaced with your own identifying information:
 !      Portions Copyright [yyyy] [name of copyright owner]
 !
 ! CDDL HEADER END
 !
 !
 !      Portions Copyright 2007 Sun Microsystems, Inc.
 ! -->

<adm:managed-object name="schema-backend" plural-name="schema-backends"
  package="org.opends.server.admin.std"
  extends="backend"
  xmlns:adm="http://www.opends.org/admin"
  xmlns:ldap="http://www.opends.org/admin-ldap">
  <adm:synopsis>
    The schema backend provides access to the OpenDS Directory Server schema
    information, including the attribute types, object classes, attribute
    syntaxes, matching rules, matching rule uses, DIT content rules, and
    DIT structure rules that it contains.
  </adm:synopsis>
  <adm:description>
    The server will allow modify operations in this backend to alter the server
    schema definitions. The org.opends.server.backends.SchemaBackend class
    provides the implementation for this backend.
    The configuration entry for this backend is based on the
    ds-cfg-schema-backend structural object class. Note that any attribute
    types included in this entry that are not included in this object class
    (or the parent ds-cfg-backend class) will appear directly in the schema
    entry.
  </adm:description>
  <adm:profile name="ldap">
    <ldap:object-class>
      <ldap:oid>1.3.6.1.4.1.26027.1.2.9</ldap:oid>
      <ldap:name>ds-cfg-schema-backend</ldap:name>
      <ldap:superior>ds-cfg-backend</ldap:superior>
    </ldap:object-class>
  </adm:profile>
  <adm:property-override name="backend-class">
    <adm:default-behavior>
      <adm:defined>
        <adm:value>
          org.opends.server.backends.SchemaBackend
        </adm:value>
      </adm:defined>
    </adm:default-behavior>
  </adm:property-override>
  <adm:property name="schema-entry-dn"
    mandatory="false"
    multi-valued="true">
    <adm:synopsis>
      This defines the base DN(s) at which the schema information will be
      published, in addition to the value included in the ds-cfg-backend-base-dn
      configuration attribute.
    </adm:synopsis>
    <adm:description>
      The value provided in the ds-cfg-backend-base-dn configuration attribute
      is the only one that will appear in the subschemaSubentry operational
      attribute of the server's root DSE (which is necessary because that is a
      single-valued attribute) and as a virtual attribute in other entries,
      but the ds-cfg-schema-entry-dn attribute may be used to make the schema
      information available in other locations as well in case certain client
      applications have been hard-coded to expect the schema to reside in a
      specific location.
    </adm:description>
    <adm:default-behavior>
      <adm:defined>
        <adm:value>cn=schema</adm:value>
      </adm:defined>
    </adm:default-behavior>
    <adm:syntax>
      <adm:dn />
    </adm:syntax>
    <adm:profile name="ldap">
      <ldap:attribute>
        <ldap:oid>1.3.6.1.4.1.26027.1.1.113</ldap:oid>
        <ldap:name>ds-cfg-schema-entry-dn</ldap:name>
      </ldap:attribute>
    </adm:profile>
  </adm:property>
  <adm:property name="show-all-attributes"
    mandatory="true"
    multi-valued="false">
    <adm:synopsis>
      Indicates whether to treat all attributes in the schema entry as if they
      were user attributes regardless of their configuration.
    </adm:synopsis>
    <adm:description>
      This may provide compatibility with some applications that expect schema
      attributes like attributeType and objectClasses to be included by default
      even if they are not requested.  Note that the ldapSyntaxes attribute
      will always be treated as operational in order to avoid problems with
      attempts to modify the schema over protocol.
    </adm:description>
    <adm:syntax>
      <adm:boolean />
    </adm:syntax>
    <adm:profile name="ldap">
      <ldap:attribute>
        <ldap:oid>1.3.6.1.4.1.26027.1.1.141</ldap:oid>
        <ldap:name>ds-cfg-show-all-attributes</ldap:name>
      </ldap:attribute>
    </adm:profile>
  </adm:property>
</adm:managed-object>