Documentation

XED Implementation Considerations

Internet Drafts

See Specifications

ASN.1 Specifications

See http://www.itu.int/ITU-T/studygroups/com17/languages/index.html

Frequently Asked Questions

What is XED?
The XML Enabled Directory (XED) framework leverages existing Lightweight Directory Access Protocol (LDAP) and X.500 directory technology to create a directory service that stores, manages and transmits Extensible Markup Language (XML) format data, while maintaining interoperability with LDAP clients, any LDAP enabled application, X.500 Directory User Agents (DUAs), and X.500 Directory System Agents (DSAs).

What are the main features of XED?
They are:
a) semantically equivalent XML renditions of existing directory protocols,
b) XML renditions of directory data.
c) the ability to accept at run time, user defined attribute syntaxes specified in a variety of XML schema languages.
d) the ability to perform filter matching on the parts of XML format attribute values,
e) the flexibility for implementors to develop XED clients using only their favoured XML schema language.

How can XED Help?
The XML Enabled Directory allows directory entries to contain XML formatted data as attribute values. Furthermore, the attribute syntax can be specified in any one of a variety of XML schema languages that the directory understands. The directory server is then able to perform data validation and semantically meaningful matching of XML documents, or their parts, on behalf of client applications, making the implementation of XML-based applications easier and faster. XML applications can also exploit the directory's traditional capabilities of cross-application data sharing, data distribution, data replication, user authentication and user access control, further lowering the cost of building new XML applications.

What is the differences between DSMLv2 and XED?
In our view DSML is half a solution. It provides an XML encoding for LDAP operations, but still assumes that directory attribute values are in the LDAP string format. If you try putting XML in directory attribute values it has to be escaped before it can be transported in DSML. Even worse, DSML represents LDAP extended operations and controls as the base 64 encoding of the octets of the BER encoding of the operation or control, which is practically indecipherable to a human reader.

The XED alternative to DSML is XLDAP (a 100% XML version of the LDAP protocol). XLDAP represents XML in directory attribute values natively as XML without escaping. It also provides an XML markup for values of existing complex syntaxes like directory schema definitions (attribute type definitions, object class definitions, etc). LDAP controls and extended operations are also represented as XML markup, never as base 64 or BER.

The XED framework allows directory attributes to be created with syntaxes defined in XML Schema, or with a DTD. The directory then understands the structure of the data and can do semantically driven verification and matching of the data. For example, the directory knows that "true" and "1" are equal values for the XSD boolean datatype, and knows how to order values of the XSD dateTime datatype with time zones. Component matching can also be invoked to match specific elements or XML attributes in directory attribute values. The best one can do with DSML is substring matching on the XML syntax, which is a bit hit and miss.