RE: Samples for DSML 2.0

[Andy Harjanto <andyhar@Exchange.Microsoft.com>]

Thanks Rob!

Two good issues you raise:
1) How does LDAP multiple inheritance class represent in XML ?  
I'm proposing to include only the lowest structural class. The
hierarchical relationship between classes (schema) should be described
somewhere-else.  So for example if we have an instance of
'organizationalPerson' which is derived from 'person' which in turns
it's derived from 'top',  we would specify only 'organizationalPerson',
for example  
   <Alice class="organizationalPerson">
       ....
   </Alice>  

For per-instance aux classes, we could add "auxClass" XML attribute.
Now, the general problem with this approach is "how do you represent a
multivalue directory attribute into an XML attribute?"  In DSML 1.0 we
represent multivalue as an element. Now that we want to design for easy
XPath access, this design infers that element relationships are
parent-child relationships. 

One way to solve this is, of course, to come up with the delimiter.
Let's assume for now we pick ';'. 

Example:

  <Alice class="organizationalPerson"
auxClass="managedBy;securityPrincipal">
       ....
  </Alice>  


This works nicely because classes can not contain ';'.  Now what happens
if we have a string which happens to have a character ';'? Now, we have
to come up with escaping mechanism. 

My point is - yes it's nice to align with XPath, but of course with a
cost( ... somebody may come up with a better approach).  



2) More granulatity on LDAP Attributes Updates (append, replace, delete,
etc)expressed in XML.

We could add the 'operation code' XML attribute in the first element. If
none is specified, we could default this to 'replace'

For examples:

*Appending attribute values: 
  <update path="guid:a7fc61cc4661924e98f5316ff060baeb" >
     <sn>Gibbs</sn>
     <telephoneNumber op="append">(425)777 7777</telephoneNumber>
     <telephoneNumber>(206)999 9999</telephoneNumber>
     <telephoneNumber>(425)888 8888</telephoneNumber>
  </update>  

*Replacing attribute values:
  <update path="dn:CN=JSmith, OU=Marketing, O=Example, C=US" >
     <sn>Gibbs</sn>
     <telephoneNumber op="replace">(523)777 7777</telephoneNumber>
     <telephoneNumber>(892)999 9999</telephoneNumber>
     <telephoneNumber>(785)888 8888</telephoneNumber>
  </update>  

*Deleting specific attribute values
  <update path="dn:CN=JSmith, OU=Marketing, O=Example, C=US" >
     <sn>Gibbs</sn>
     <telephoneNumber op="delete">(523)777 7777</telephoneNumber>
  </update>  



Thanks!


-----Original Message-----
From: Rob Weltman [mailto:robw@worldspot.com]
Sent: Tuesday, October 31, 2000 9:20 AM
To: Andy Harjanto
Cc: James Tauber; dsml@lists.oasis-open.org
Subject: Re: Samples for DSML 2.0


> Andy Harjanto wrote:
> 
> 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>


Andy,

  One of the issues I've had from the get-go with the relationship
between LDAP and XML is that LDAP allows multiple inheritance, while XML
doesn't. In the example above, MyCompany implements a single class (an
XML attribute is single-occurrence). What if you want to instantiate an
object which is both an organizationalPerson and a myCompanyPerson? How
do you express that in the XML schema for the document containing the
object? I think that problem is what led to the meta-descriptive
approach taken in DSML 1.0.

  See more comments below.


> 
> 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.

  That is the major attraction in my mind of treating a directory (or
extract of it) as an XML document.


> 
> 
> 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>

  In LDAP, you can delete a particular value of a particular attribute,
delete all values of a particular attribute, replace a particular value
of a particular attribute, replace all values of a particular attribute,
or add a value or values to an attribute.


> 
> 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

  Thanks for taking the initiative!

Rob