[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: Samples for DSML 2.0
Technically, I agree with you on the second point ie. the scope of the
op attribute is limited to the enclosing element. I was thinking of more
in term of usability. It's probably unlikely that an attribute will be
appended and deleted in one call. It's more likely a user does one
operation at a time (append only, delete only, etc) for a given
attribute. But, I can see the value of your argument, and agree w/ your
approach.
For the first issue; First of all, are we in the agreement we're going
to support XML-Schema in DSML 2.0 (http://www.w3.org/2000/08/XMLSchema)
?
Thanks.
-----Original Message-----
From: Rob Weltman [mailto:robw@worldspot.com]
Sent: Thursday, November 02, 2000 2:10 PM
To: Andy Harjanto
Cc: James Tauber; dsml@lists.oasis-open.org
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