[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: moving forward with proposals
I'm not familiar with XDAP, but is your concern is not so much with the syntax of DSML (how to represent schema, data, and operations), but that interoperability between two different schemas and namespaces haven't been addressed. To me those are both very important issues, but in two different steps. I think DSML should be focused on the syntax first. Then I think common schemas can be proposed as standards so that two different parties can exchange the same date using DSML. My concern with tackling both issues at the same time is that in different markets or collaborative environments, the schemas, or information content, could be quite different. Therefore it may be hard to get real adoption if too much content is put into the DSML effort. Since there are holes in just the basics in DSML 1.0, I suggest rounding out those capabilities as quickly as possible and then address standardizing content. It would be nice if the standard was beyond that stage so we could get to those issues, but its not. Tony -----Original Message----- From: John McGarvey [mailto:mcgarvey@us.ibm.com] Sent: Wednesday, June 20, 2001 12:42 PM To: Tony Gullotta Cc: DSML (E-mail) Subject: Re: moving forward with proposals I am a little concerned about the current state of the proposals. I would summarize them as follows: 1. Microsoft proposal and Access360 proposal: DSML 2 will be like DSML 1, in the sense that it will be an XML encapsulation of LDAP data and operations. 2. iPlanet proposal: There is some provision for program exits to resolve differences between directory schema; however, the resultant output is dependent on the unspecified behavior of these exits. 3. Novell DirXML: This proposal includes schema mapping, as might be used within a metadirectory. The schema that is mapped to is the Novell eDirectory native schema. This is a very crude summary, and I have done some violence to the meaning of the documents: please see the originals. Today, LDAP applications are written to work with specific LDAP servers. An application written for one LDAP server implementation may fail to work with another, primarily because schema and namespace are not standardized. In fact, applications written for the same LDAP server implementation may not coexist, or may coexist with minimal reuse of directory data, because of different naming assumptions in the applications. DSML 1.0 does nothing to solve these interoperability issues, because it is just a raw encapsulation of LDAP data in XML. As a result, DSML 1.0 applications have all the same interoperability issues as LDAP applications do. If the Microsoft or Access360 proposals are adopted, the same will be true of DSML 2.0. This is an especially serious problem for pervasive devices -- such devices should not be burdened with the logic needed to interpret differing directory data. In this context, XDAP is an interesting proposal, as it is independent of specific schema, namespace, or directory technologies. XDAP schema are provided for DNS information. If the XDAP schema were extended to the most common directory objects, especially users and groups, and were also extended to include create, modify, and delete operations, it could enable the creation of fully interoperable directory applications. On the other hand, there are many LDAP operations that can't be performed using XDAP, unless it is extended, and there is no bound on the list of extensions needed. At least with the Microsoft and Access360 proposals, the full capability of the directory would be accessible. I suggest that what is needed is a hybrid proposal, supporting all LDAP operations and objects, but also providing, as a mandatory part of the standard, operations on a subset of the directory objects, independent of specific schema and namespace. This subset would include search, create, modify, and delete on users, groups, and a small list of other object classes. Applications built using this subset would work with any directory implementing DSML 2.0. Intelligence to map between schema and namespace differences would reside, not in the client or device, but in the DSML gateway. Is there interest in this approach? John McGarvey (opinions expressed are my own) Tony Gullotta <TGullotta@access360.com> on 06/19/2001 05:29:06 PM To: "DSML (E-mail)" <dsml@lists.oasis-open.org> cc: Subject: moving forward with proposals We've seen a few proposals from different groups for DSML 2.0 lately. Microsoft's was the most recent. What are the next steps for getting a consensus on a direction to take? Our group had sent in one, but I would much rather reach a compromise with someone else's approach at this point to get the standard in place instead of having a stand-off. Microsoft's was similar enough to ours in principal that I think we could work with that one. Does anyone else strongly favor or strongly apose any of these recommendations? Tony Gullotta Chief Software Architect www.access360.com access360 A Better Way to Manage Access Rights
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC