Re: Fw: DSML 2.0 requirements

[rweltman@netscape.com (Rob Weltman)]

"dugan(ibm)" wrote:
> 
> My comments below.
> 
> -M
> ----- Original Message -----
> From: Rob Weltman <rweltman@netscape.com>
> To: <dsml@lists.oasis-open.org>
> Sent: Wednesday, August 30, 2000 1:46 PM
> Subject: DSML 2.0 requirements
> 
> >   To kick off the requirements discussion, I'll summarize (and augment)
> some thoughts that I > presented at the phone conference yesterday.
> >
> > - There are fairly well-established APIs and SDKs for accessing LDAP data
> for most of the popular >programming languages: C/C++, Java, perl, TCL,
> python, VB. There are many applications that are >LDAP-aware and are using
> these SDKs and APIs. Those applications and their owners are not the >target
> audience for DSML 2.0.
> 
> I'd like to suggest that most of the programs written in these languages
> will either produce dsml or parse it using their "native" directory support
> to process dsml. I'm uncertain how we can state that the programmers in
> these languages would not be a target for 2.0; I'd anticipate that this
> group would be a big target  audience since the bulk of dsml processors
> would probably fall out from this group.

  The distinction is not between programmers using popular languages on the one hand, and those not using popular languages on the other hand. The distinction is between programmers familiar with and using existing LDAP APIs, and those not familiar with or using existing LDAP APIs. DSML doesn't help the former category much. Their applications work fine using LDAP and they have no reason to change. But DSML will make it much easier for the latter category to access LDAP data (assuming XML is in their environment).


> > - There are many more applications that are clueless WRT LDAP but which
> would benefit from
> > access to user (and potentially other) information stored in a directory.
> XML is the only real
> > contender for a common data format for information exchange across a wide
> range of application
> > areas, and I expect that most new applications with wide-ranging data
> interchange requirements
> > (and even many without such strong requirements) are or will be XML-aware.
> These applications
> > and their owners are the target audience for DSML 2.0.
> >
> > - DSML 2.0 should make it as painless as possible for non-LDAP-aware
> applications to access
> >(read/create/update/delete) information which is managed by LDAP servers.
> 
> Perhaps allow "power" applications to perform the functions they need to do
> (ie, ldap controls,
> extensions)? If the spec is too weak a large group of developers will
> probably abandon it since
> it won't satisfy their needs.

  Definitely. We need more precise definitions of what can be done with DSML. My bullet was just a very broad outline.


> > - We discussed the concept of representing each LDAP protocol operation in
> XML. I am not >convinced at this point that such an approach would provide
> all the benefits to non-LDAP-aware >clients that the XML environment makes
> possible. I don't know how realistic it is, but an ideal XML >view of the
> LDAP world would be as just another XML document, where XLink is used to
> identify >directory entries (roots of subtrees) and XPath to query and
> extract entries and attributes within a >subtree.
> 
> I'm unclear why it can't do both. A directory agnostic piece that non-LDAP
> aware apps can take advantage of and perhaps a directory specific component
> for apps that need access to all of the underlying directory's features.

  It is very likely that, even if we find we can do almost everything with XPath, we will need to provide an escape mechanism for passing non-generic parameters or information (although we might still be able to express them with XPath syntax, which is quite general). But the question here was more: do we start with one of the existing LDAP APIs (or the ASN.1 representation of the LDAP protocol operations) and translate into XML, or do we start with the generic languages for processing XML documents (XPath, XPointer, XLink, XSLT) and investigate how they apply to LDAP?

  James expressed reservations as to if XPath fits the bill entirely for a query language for directory content. I'm not disagreeing because I really don't know yet. But I think it is such an interesting concept (it would make directory content very accessible to XML developers) that we need to look into it within the framework of the DSML 2.0 work.

Rob