[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Comparison (DAML, DirXML, XMLDAP) - Text and MS Word Version
I did not know the uploading of a PDF will changing to a bin file format. For the previous file, please open with Adobe Acrobat. I am also including the Word version under the text below.
Comparison of Technologies Submitted for the DSML 2.0 Specification
Draft
April 4, 2001
Prepared By:
Jeff Bohren, Access360
Introduction
Directory Services Markup Language (DSML) is a proposed standard for representing LDAP in XML. The first version (1.0) of DSML defined how to represent LDAP schema and data, but did not address LDAP operations and protocol issues.
This paper is a summary of three technologies that have been submitted to the DSML organization for consideration as the next generation (2.0) for the DSML standard.
Note: The author of this paper is one of the co-authors of the DAML specification, and is much more familiar with DAML than the other evaluated technologies.
Directory Access Markup Language (DAML), Submitted by Access360
Access360 has offered the DAML specification to DSML.org for consideration as part of the DSML 2.0 specification. The DAML specification was defined by Access360 as the protocol for communication to agents. To be as standards based as possible, the DAML syntax matches the LDAP syntax very closely, but is represented as XML text rather than BER encoded data (which is how LDAP is represented). Also, the DAML specification was designed to leverage the DSML 1.0 specification.
DIR-XML, Submitted by Novell
Novell has submitted a XML specification (NDS-DTD) that is currently part of the Dir-XML product for consideration as part of the DSML 2.0 specification. The NDS-DTD is designed mainly to support the concept of an LDAP join engine (system that keeps data from 3rd party data sources synchronized with it's representation in an LDAP directory).
Although some parts of the NDS-DTD could be used independently, the XML definitions assume that this is being used in the Dir-XML product in conjunction with the Novell Directory Server.
XMLDAP, Submitted by iPlanet
iPlanet has submitted the XML schema from the iPlanet XMLDAP Directory Gateway (iXDGW) product to DSML.org for consideration as part of the DSML 2.0 specification. The XMLDAP, unlike DAML and Dir-XML, does not define an XML DTD. Instead, it defines a generic template specification that can be used in conjunction with their product to transform representation of data in XML from one form to another. They then define a default implementation of that transformation language that can transform LDAP like data. The part that is applicable to DSML is the eXstensible Template Language (XTL) with an associate set of tags for representing LDAP.
The transformation mechanism defined in the iXDGW for handling LDAP is designed primarily to support the embedding LDAP operations in a Web Page. Although this could be used independently for generic LDAP operations, it requires the use of a transformation mechanism that is unnecessary in most cases.
Comparison Matrix
DAML (Access360) NDS-DTD (Novell) XMLDAP (iPlanet)
LDAP Schema Representation Yes1 Yes No2
LDAP Data Representation Yes1 Yes2 Yes
Distinguished Names (DNs) Yes1 Partial3 Yes
Bind Request Yes Implicit4 Implicit4
Bind using SASL Yes No No
Add Request Yes Yes Yes
Modify Request Yes Yes Yes
Search Request Yes Yes Yes
Search Scope Control Yes Yes Yes
Search Size/Time Limit Control Yes No No
Recursive Search Filters Yes No5 Implicit6
Rename Request Yes Yes No
Move Request Yes Yes No
Compare Request Yes No No
Extended Request Yes No No
Message ID Yes No No
Standard LDAP Error Codes Yes No No
Incomplete Modifications Returned Yes No No
Uses DSML 1.0 Yes No No
Matches DSML 1.0 Naming Convention No Yes Yes
Product Independent Yes No7 No8
Vendor Independent Yes No7 Yes
Protocol Independent Yes Yes Yes
1. DAML uses DSML 1.0 syntax for this feature.
2. No direct support for schema definitions, but LDAP Schemas can also be defined as LDAP data.
3. The NDS-DTD requires mappings be created between DNs as they are known to both the client and the server.
4. Instead of being an explicit operation, the bind request is always part of another request. The disadvantage of this is that when doing multiple requests in a single connection, the bind information must be sent with every request, which not required in LDAP.
5. The NDS-DTD only allows filters to be defined as a flat list of attribute values assertions, rather than a recursive list of filters that LDAP allows.
6. iXDGW represents search filters as a string, which allows for recursive filter definitions, but puts the onus on the server to parse the filter text to support this.
7. Although some parts of the NDS-DTD could be used independently, the top-level of the XML definition assumes the use of the Novell Dir-XML product and the Novell Directory Server. Additionally, the way the LDAP operations are represented implies the use of a join engine with features similar to Dir-XML.
8. Although not explicitly tied to the iXDGW product, the mechanism for defining LDAP operations requires the use of XTL or an equivalent transformation capability.
Conclusions
Of the three technologies considered, only DAML is designed to address the specific issue of representing LDAP schema, data, and operations in XML. The NDS-DTD was designed for use with an LDAP Join Engine and the IPlanet XTL and XTL LDAP tags were designed to combine LDAP operations in Web pages. While these are both useful ideas, they should be considered outside of the scope of the DSML organization.
DAML was also the only one of the three technologies that made use of the DSML 1.0 schema. DAML was designed from the start to be a supper-set of DSML 1.0, and was designed to address the issues that DSML 1.0 did not cover. The DAML specification was not, however, written using the same naming convention (all lower case with hyphens), as was DSML 1.0. This was done to conform to the naming conventions used more frequently in Access360 for defining XML (mixed case, no hyphens).
DAML was designed to support all of the features found in the LDAP V3 specification, as defined in RFC 2251, where as the other technologies only support the most commonly used features.
DAML was designed to be completely vendor and product neutral. Although it is used by Access360 for enRole server to agent communications, there is nothing in the specification that is tied to that use. There is also nothing in the DAML specification, other than the copyright header, that refers to Access360 or any Access360 products.
Of these three technologies DAML is the closest fit for where DSML is currently focused in the 1.0 specification, and for where DSML will likely be focusing in the 2.0 specification. If the scope of DSML 2.0 is expanded to include other issues besides supporting standard LDAP schema, data, and operations, then one of these other technologies may be more applicable.
<<compare.doc>>
-Gavenraj Sodhi
gsodhi@access360.com
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC