Re: [dsml] An augmentability example: DSML v.2 ModifyRequest

["Tom Doman" <TDoman@novell.com>]

I would modify one thing in my example if additional choices are allowed to be added through an xsd:extension like so.

 

 <xsd:complexType name="MyAugmentedSampleDSModification">

  <xsd:complexContent>
   <xsd:extension base="MySampleDSModification"/>

    <xsd:choice>

     <xsd:element name="test" type="MySampleFilter"/>
     <xsd:element name="addAttribute" type="MySampleAttribute"/>
     <xsd:element name="addAdditional" type="MySampleAttribute"/>
     <xsd:element name="overwrite" type="MySampleAttribute"/>
     <xsd:element name="clear" type="MySampleAttribute"/>
   </xsd:choice>

  </xsd:complexContent>
 </xsd:complexType>

I believe this to be legal XML Schema and, as such, this would be a preferrable extension method since it references the "standard" which in the example is MySampleDSModification.  Of course, again, this is only an available option if the "standard" is done in a way that allows it.

It would be nice if XML Schema also provided a way to say that a certain type and any derivative is allowed.  Then, in the example, we would not have to create "MyAugmentedSampleModifyRequest" simply to specify our derived type.  This would allow us to better model LDAP ASN.1 which implicity extensible in this manner.

 

Tom Doman

tdoman@novell.com

>>> "Tom Doman" <TDoman@novell.com> 3/27/2003 4:45:29 PM >>>

An example of how we might change the DSML v.2 *ModifyRequest* that overcomes some of the shortcomings that Jim referred to might help.  We're not neccessarily looking for a model that can be extended using an <xsd:extension ..> construct (although that would be nice where possible), rather, a model than can be contained within a brand new schema that still allows support of "THE standard" schema directly, but may be augmented to allow additional content.  For the current DSML v.2 ModifyReqest, the definition does lend itself to the addition of new operations where types other than a DsmlValue are acceptable (at least, not in a non-kludgey way).  Also, the liberal use of attributes instead of elements restricts the augmentability of a given type definition since they cannot contain complex types.  Here's how we might change the ModifyRequest:

 

 <xsd:complexType name="MySampleAttribute">
  <xsd:sequence>
   <xsd:element name="name" type="AttributeDescriptionValue" />
   <xsd:element name="value" type="DsmlValue" minOccurs="0" maxOccurs="unbounded"/>
  </xsd:sequence>
 </xsd:complexType>

 <xsd:complexType name="MySampleDSModification">
  <xsd:choice>
   <xsd:element name="add" type="MySampleAttribute"/>
   <xsd:element name="delete" type="MySampleAttribute"/>
   <xsd:element name="replace" type="MySampleAttribute"/>
  </xsd:choice>
 </xsd:complexType>

 <xsd:complexType name="MySampleModifyRequest">
  <xsd:complexType>
   <xsd:complexContent>
    <xsd:extension base="DsmlMessage">
     <xsd:sequence>
      <xsd:element name="dn" type="DsmlDN"/>
      <xsd:element name="modification" type="MySampleDSModification" minOccurs="0" maxOccurs="unbounded"/>
     </xsd:sequence>
    </xsd:extension>
   </xsd:complexContent>
  </xsd:complexType>
 </xsd:element>

Now, if this was how "THE standard" was defined, I could take it and augment it while supporting both documents that were formed using the standard as well as those formed using my augmented schema.  For example, my augmented schema might look like this:

 

 <xsd:complexType name="MySampleFilter">
  <!-- Maybe something a lot like a search filter if not just search filter. -->
 </xsd:complexType>

 <xsd:complexType name="MyAugmentedSampleDSModification">
  <xsd:choice>
   <xsd:element name="add" type="MySampleAttribute"/>
   <xsd:element name="delete" type="MySampleAttribute"/>
   <xsd:element name="replace" type="MySampleAttribute"/>

   <xsd:element name="test" type="MySampleFilter"/>
   <xsd:element name="addAttribute" type="MySampleAttribute"/>
   <xsd:element name="addAdditional" type="MySampleAttribute"/>
   <xsd:element name="overwrite" type="MySampleAttribute"/>
   <xsd:element name="clear" type="MySampleAttribute"/>
  </xsd:choice>
 </xsd:complexType>

 <xsd:complexType name="MyAugmentedSampleModifyRequest">
  <xsd:complexType>
   <xsd:complexContent>
    <xsd:extension base="DsmlMessage">
     <xsd:sequence>
      <xsd:element name="dn" type="DsmlDN"/>
      <xsd:element name="modification" type="MyAugmentedSampleDSModification" minOccurs="0" maxOccurs="unbounded"/>
     </xsd:sequence>
    </xsd:extension>
   </xsd:complexContent>
  </xsd:complexType>
 </xsd:element>

 

Now, understand that I think I could safely classify Jim and myself as XML Schema neophites so we are quite possibly missing some elegant construct or methodology which would accomplish what we're looking for.  However, we have been developing directory services at Novell for many years.  Note that we would also prefer that the "dn" attribute be changed to an element to allow the possibility of allowing a new complex type that would encompass DsmlDN (xsd:string) while still supporting it in that new complex type (perhaps through an xsd:union? ... don't want to take the time to figure it out right now but I know I don't have a prayer if it's a attribute).

 

Comments?

 

Thanks,

Tom Doman

tdoman@novell.com