OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

dsml message

[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