[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Re: Samples for DSML 2.0
Andy Harjanto wrote: > 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). > How would you validate the XML schema of Alice? I don't think you can (with a standard parser); you would have to have a special validator that reads the class and auxClass attributes, composes a merged schema, and then applies it to the contents of the Alice element. A couple of XML gurus have told me it is possible to solve the multiple inheritance problem, but I haven't seen it done yet. > 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> > The scope of the op attribute is limited to the enclosing element, so it would have to be: *Appending attribute values: <update path="guid:a7fc61cc4661924e98f5316ff060baeb" > <sn>Gibbs</sn> <telephoneNumber op="append">(425)777 7777</telephoneNumber> <telephoneNumber op="append">(206)999 9999</telephoneNumber> <telephoneNumber op="append">(425)888 8888</telephoneNumber> </update> Same for the other types. That means you can combine operations in a single <update/> element, just as you can with a single LDAP modification request: *Appending attribute values: <update path="guid:a7fc61cc4661924e98f5316ff060baeb" > <sn>Gibbs</sn> <telephoneNumber op="delete">(425)777 7777</telephoneNumber> <telephoneNumber op="append">(206)999 9999</telephoneNumber> <telephoneNumber op="append">(425)888 8888</telephoneNumber> </update> Rob > > *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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC