[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC