Re: Object class defintion (and X.500 and other directories)

[Rob Weltman <robw@worldspot.com>]

Erik,

  DSML version 1 models the LDAP/X.500 data representation closely. For version 2 we are trying to generalize the representation so that it will be a more natural fit for contexts where XML is being used for other purposes; a side effect is that we think the representation will work for other data sources than LDAP, but that is not a goal in itself.

  Andy Harjanto of Microsoft sent out an initial proposal for what the new representation could look like on October 30. There has been some discussion around it since then, but no new proposal. Andy's message was as follows.

Rob
 

<Andy>

James sent out few proposals on requirements, DSML operations, and Directory draft data model a month ago. Since then, we have made a little progress.  I would like to propose a few samples to stimulate the discussion again. IMHO, discussing real samples allows us to make an incremental progress while making sure we're on the same page.

In simple term; this is what my understanding so far. Others are welcomed to correct me.

1) Directory data model which allows easy XPATH navigations and queries. The model is not neccessarily backward compatible with DSML version 1.0.

2) Representing LDAP Operations in an XML document.

Note: 1) and 2) may be combined latter in a document, but let's talk this separately for now.

We agreed to use SOAP as the transport (and possible method executions), but let's side aside this for moment, and concentrate on the XML model.

Proposed XML documents.
The samples, by all means, are not intended to cover all the possiblities, rather, they are just used illustrate important points.

1) Represent Directory data model in XML.
<...omit the XML namespace for moment, I would like to focus on the format>.
The goal is to be able to produce an XML document which represents directory data model but it could easily be accessed via XPATH.

General Format:
<objectName-value  someattribute="..."  ... >
    <childName-value someattribute="..." ...>
    </childName-value>
    <childName-value someattribute="..." ...>
         <grandchildName-value  someattribute="...">
               <...>
               </...>
         </grandchildName-value>
         ...
    </childName-value>
      ...
</objectName-value>

   * XML element maps to objectName.  Note: XML element can not contain space, where LDAP object Name can.
   * XML attribute maps to object's attribute

Examples:
<MyCompany  rdn="OU=MyCompany"  dn="..." description="..." class="..." >
    <SalesAndMarketing rdn="OU=SalesAndMarketing"  homePage="..." class="..." >
         <Consulting  rdn="CN=Consulting" >
         </Consulting>
   </SalesAndMarketing>
   <ResearchAndDevelopment rdn="OU=ResearchAndDevelopment"  description="...">
          <ProductX rdn="CN=ProductX"  startDate="01/02/1998">
         </ProductX>
         <ProductY rdn="CN=ProductX"  startDate="04/02/1999">
         </ProductY>
   </ResearchAndDevelopment>
</MyCompany>

Example Queries:
 a) Get all objects in R&D
     MyCompany/ResearchAndDevelopment//

 b) Get all products under development since 1999
    MyCompany/ResearchAndDevelopment//[@startDate >= "01/01/1999"]

 c) Get ProductX.    MyCompany/ResearchAndDevelopment/ProductX

 d) Enumerate children in SalesAndMarketing.    MyCompany/SalesAndMarketing/*

 etc, etc.
 

Notes:
* In a high unlikely event, what if you don't have permission to view parent's object, but we could view child's object? How do we represent this ?
 
 

2) LDAP Operations in XML format.
My proposal is to come up with words that are common to data access terminology, rather than using LDAP jargons. The samples only cover common operations.

General XML operation format

<an_operation  path=”…”>
</an_operation>

Path value identifies the targeted object where the operation will be applied.  Potential formats supported are:

·    Distinguished name. For example, “dn:OU=Developers,DC=example,DC=com”
·   GUID.   For example, “guid:a7fc61cc4661924e98f5316ff060baeb”

The idea is to create an extensible
scheme, where each vendors might have a different way to identify an object
in the directory. At the minimum, each vendor must support dn path; e.g  
"dn:..."

Updates

<update path="…" >
       <attribute_name>…</attribute_name >
        <attribute_name>…</attribute_name >
 </update>

Create

<create path="…" class="…" name="…">
     <attribute_name>…</attribute_name>
     <attribute_name>…</attribute_name>
</create>

Delete

<delete path="…">
</delete>

Move

<move path="…">
     <to path="…" />
</move>

Rename ( we could have combined with
Move, but IMHHO, people understand rename clearly)

<rename path="…">
      <name>…</name>
</rename>

LDAP Operations Examples:

 <update path="guid:a7fc61cc4661924e98f5316ff060baeb" >
       <sn>Gibbs</sn>
      <telephoneNumber>(425)777 7777</telephoneNumber>
 </update>
 <create path="dn:CN=Samuel Heinz,OU=Marketing,O=Example, C=US" class="user" name="Samuel Heinz">
     <samAccountName>sammisas</samAccountName>
    <userPrincipalName>sam@example.com</userPrincipalName>
</create>

<move path="ad:fabrikam.nttest.microsoft.com/Marketing/Bob Adams">
     <to path="ad:fabrikam.nttest.microsoft.com" />
</move>
<move path="dn:CN=Bob Jones,OU=Marketing,O=Example, C=US">
     <to path="guid:a7fc61cc4661924e98f5316ff060baeb" />
</move>
 

Comments ?

Thanks
andy

</Andy>
 

Erik Andersen wrote:

Hi Rob (and others),

Thanks Rob for your thorough answer.

I am interested in DSML for the following reasons:

European International Directory Inquiry (EIDQ) is a consortium among
Telecoms in Europe to provide an international (and national) directory
assistance service, where the telephone operators are currently the prime
users. Their current directories are based on ITU-T E.115, To cope with
extended requirements, EIDQ has considered using X.500 for the next
generation of directory systems. We have developed substantial extensions
to X.500 to support the EIDQ requirements as they are expressed in ITU-T
Rec. F.510 "White Pages Service". EIDQ members have become concerned that a
full-blown X.500 system is too complex to operate. Also, they want to use
the current, very efficient databases. The current thinking is therefore to
make a cut-down version of X.500 that is tailored to EIDQ requirements.
Such a directory specification will be quite different from LDAP, but will
have something in common, such as the basic X.500 model, although the EIDQ
databases do not reflect a DIT or have the concept of distinguished name.
Also the object classes and attribute types are quite different, very
special matching rules are used, etc.

EIDQ considers to use XML for the definition of the cut-down access
protocol.

X.500 is seen as an important component within electronic commerce.
Especially, the extensions developed for EIDQ will also prove very useful
within e-commerce. However, e-commerce would require an XML based access
protocol.

All this leads me to the idea to develop a general XML based access
protocol that will cover LDAP, X.500, EIDQ and possibly E.115 requirements.

What would the attitude be within the DSML group on such an approach?

Is there a DSML version 2 draft available?

Erik Andersen
CEN/ISSS/WS-DIR Chairman
Mobile: +45 20 97 14 90
E-mail;  era.als@get2net.dk
Internet: http://www.cenorm.be/isss/Workshop/DIR/Default.htm

-----Original Message-----
From:   Rob Weltman [SMTP:robw@worldspot.com]
Sent:   Thursday, December 28, 2000 3:30 AM
To:     Erik Andersen
Cc:     Dsml-List (E-mail)
Subject:        Re: Object class defintion

Erik Andersen wrote:
>
> Please excuse stupid question from a new-comer on the list.
>
> I have studied that DSML version 1 specification and have some questions
> concerning the object class definition. The class element has the id
> attribute that identifies the object class. It also has a name child
> element. How does the value(s) given in the name child element relate to
> the value given id attribute? Also, why can there be several occurrences
of
> the name child element?
>
> Erik Andersen

  The "name" element defines the name of the object class, e.g.

<dsml:name>inetOrgPerson</dsml:name>

  The "id" attribute defines a symbol which can be used to refer to the
definition from elsewhere (in this or another XML document) using XLink
notation, e.g.

<dsml:class id="organizationalPerson" ...>
  <dsml:name>organizationalPerson</dsml:name>
...
</dsml:class>
...
...
<dsml:class id="inetOrgPerson" superior="#organizationalPerson" ...>
  <dsml:name>inetOrgPerson</dsml:name>
...
</dsml:class>

  The second definition refers to the first one through the id attribute.
 I don't think there is any requirement that the same identifier be used
for the name of the object class and the id attribute, but using the same
identifier makes it easier to read and to debug documents containing
references.

Rob

)