[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Re: DAML, DirXML, DSML 2.0 - let the fun begin
Let me introduce myself. My name is Scott Isaacson. I am with Novell and I was part of the team that worked to make the DirXML spec publically available and to submit the spec as a working proposal into this DSML working group. I am obviously new to this working group and mailing list, so I thank Rob for pointing to the links that give the back ground and summary of where this working group has been, also for kicking of the discussion. I will take the time to read through the archives and get myself up to speed.
Regarding the first focus point, the DirXML submission is just a DTD right now; we do have interest in moving towards XML Schema. 10 years ago, in NDS we started out with typed names, but have since learned that both users and developers want to move to typeless names. In eDirectory all interfaces support typeless names. Therefore in DirXML for src-dn and dest-dn, usage is with typeless names. We agree with Andrew that operations can be on ID (in his example path="guid:adflaksjdflkjadf....") or on FDN (path="dn:CN=Bob Jones,OU=Marketing,O=Example, C=US"). We should also allow operations on what DirXML calls AssociationID which is an application specific ID that is maintained by the driver and enabled by the DirXML engine. It is an optimization that can be helpful (sequential access vs random access).
Regarding the second, the top level elements are <input> and <output>. Input documents
contain exactly one <input> element. They are used to send commands to an XML driver that front-ends the directory. They are also used by the XML driver to post events about mods or changes in the directory. <input>'s are used to initiate activity. Output documents contain exactly one <output> element and they are used used to return a response to an input document.
An example of an input element is:
<input>
<add class-name="User"
src-dn="Users\Julia"
dest-dn="cn=Julia,o=Users"
event-id="0">
<add-attr attr-name="Surname">
<value type="string">Gulia</value>
</add-attr>
</add>
</input>
A sample corresponding response could be:
<output>
<status event-id="0" level="success"/>
<add-association dest-dn="Users\Julia">JuliaGulia1</add-association>
</output>
Events and commands that can be children of an <input> element are:
<add>
<modify>
<delete>
<rename>
<move>
<query>
There are some others, but they are more interesting only to exception handling.
Events and commands that can be children of an <output> element include:
<status>
<instance>
<add-association>
Attributes common to many events and commands include:
class-name - The name of the base class of the object.
dest-dn - The DN of the target object for commands.
dest-entry-id - The entry id of the target object for commands.
event-id - An identifier used to tag the results of an event or command.
src-dn - The DN of the source object for events.
src-entry-id - The entry id of the source object for events.
timestamp - Reserved for use by the DirXML engine.
Content elements that are common to many events and commands include:
<association>
<value>
<component>
An example of a modify event where the surname was changed is:
<modify class-name="User" src-dn="Users\Julia" event-id="0">
<association>JG0U812</association>
<modify-attr attr-name="Surname">
<remove-value>
<value type="string">Gulia</value>
</remove-value>
<add-value>
<value type="string">Imbruglia</value>
</add-value>
</modify-attr>
</modify>
An example of a rename command
<rename
class-name="User"
src-dn="Users\JImbruglia"
old-src-dn="Users\Julia" event-id="0">
<association>JG0U812</association>
<new-name>JImbruglia</new-name>
</rename>
In addition to the commands and events there are four types of rules for performing well-defined event-to-command transformations:
Schema Mapping Rules
Matching Rules
Create Rules
Placement Rules
These rules are defined as XSLT stylesheets. Schema rules help map between such differences as class=User and class=inetOrgPerson. Matching rules are often applied before a create or add and describe how tight the filter is for determining if an exiting object "matches" the to-be-added object. Create Rules determine if it is permissible to generate an <add> command as a result of an <add> event. Placement Rules are used to generate a dest-dn attribute value on an <add> command generated as the result of an <add> event. Placement Rules are only applied after any Create Rules determine that the add operation is allowed. That is, if an object needs to be created but there is no explicit context, then placement rules define the hueristics for making the placement decision.
Scott
************************************************************
Scott A. Isaacson
Open Standards, CTO Group
Novell Inc.
The Leading Provider of Net Services Software
www.novell.com
M/S PRV-H-822
1800 S Novell Place
Provo, UT 84606
voice: (801) 861-7366
toll free: (800) 453-1267 x17366
cell: (801) 376-8125
fax: (801) 861-2220
email: sisaacson@novell.com
************************************************************
>>> Rob Weltman <robw@coscend.com> 04/04/01 10:13PM >>>
After a hiatus of a few months, it's time to restart the discussions on the goals and direction of DSML 2.0. When we last met (virtually speaking), Andy Harjanto of Microsoft had put together a strawman proposal for what DSML 2.0 could look like.
See:
http://lists.oasis-open.org/archives/dsml/200010/msg00004.html
and the discussion that followed (Samples...) in:
http://lists.oasis-open.org/archives/dsml/200011/maillist.html
The two main focus points of the discussions were:
- Can LDAP's aggregation of object classes in an entry be represented in XML in a way that is compatible with XML Schema, with higher-level object rendering than DSML 1.0 (which was pretty much a transliteration of LDIF into XML)?
- Should LDAP operations (add, modify, delete, moddn, search) be represented as XML elements, or is it possible/desirable to express them as XPath/DOM operations on a directory as a virtual XML document?
Andy's proposal didn't solve the first problem, and adopted the "operation as XML element" approach to the second one. 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>
<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>
<update path="dn:CN=JSmith, OU=Marketing, O=Example, C=US" >
<sn>Gibbs</sn>
<telephoneNumber op="delete">(523)777 7777</telephoneNumber>
</update>
-----------------------------------------------------------------
Fast forward to March 2001 and we have three new contributions:
DAML http://lists.oasis-open.org/archives/dsml/200103/msg00003.html
DirXML http://lists.oasis-open.org/archives/dsml/200103/msg00004.html
XMLDAP http://lists.oasis-open.org/archives/dsml/200103/msg00001.html
Here is my brief summary:
DAML is an XML wire-level alternative to ASN.1 for LDAP. It's an interesting idea, and it could have saved many of us a lot of difficult debugging if it had been the wire protocol of choice for LDAP. But I'm not sure where it fits in with application-level access to directory data.
DirXML is a more extensive language along the lines of DSML 1.0 (but different) for representing directory entries and adopting the "operation as XML element" approach for representing directory operations. The submitted documents are HMTL versions of DTDs. It would be nice to have an overview, or a complete sample document conforming to the DTDs, but I think I see representations for all the LDAP operations referenced in DTD-TREE.html. I don't see how you can express a search other than exact match on an attribute value (e.g. no substring match), though. DirXML looks (from the submitted DTDs) like a schema for synchronization between an NDS directory and an application.
XMLDAP is an XML gateway to LDAP - not in itself an XML language for accessing directories. However it includes an XML tag library for acessing LDAP directories using another "operation as XML element" approach. XTL (XML Template Language, the language that includes LDAP access tags) is used to inject directory data into an XML document as part of page preparation (HTML, WML, other XML). XTL doesn't include an XML representation of directory entries.
Hopefully that was enough fuel to reignite the discussions on this mailing list and get us moving towards (first milestone) a requirements document.
Rob
------------------------------------------------------------------
To unsubscribe from this elist send a message with the single word
"unsubscribe" in the body to: dsml-request@lists.oasis-open.org
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC