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

Can anyone tell me how an "xsd:anyType" element is processed by an XML Schema validator? Will the contents be validated against a schema? I'd like there to be a way to specify that anything is allowed so long as it follows "some" XML Schema, not just well formed XML. It seems like "xsd:anyType" would just require well formed XML, not conformance to some XML Schema. Here's an example that hopefully would illustrate the question better. What's the functional difference between the following two items?

...

<xsd:sequence>
<xsd:element name="requestName" type="NumericOID"/>
<xsd:element name="requestValue" type="xsd:anyType" minOccurs="0"/>
</xsd:sequence>
...

...

<xsd:sequence>
<xsd:element name="requestName" type="NumericOID"/>

<xsd:element name="requestValue" minOccurs="0">

<xsd:complexType>

<xsd:sequence>

<xsd:any processContents="lax"/>

</xsd:sequence>

</xsd:complexType>

</xsd:element>

</xsd:sequence>
...

As I stated, my guess would be that for number 1, instances of <requestValue> would not have their values checked against any schema where number 2 would as long as that schema could be located. Maybe there is no difference. Can anyone share some insight?

Thanks,

Tom Doman

tdoman@novell.com

>>> "Tom Doman" <TDoman@novell.com> 4/1/2003 5:04:35 PM >>>

I don't believe my earlier extension example would work exactly as desired. I think it would result in two choices rather than one that I desired. Here's another stab:

<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:any namespace=##any processContents="lax"/>
</xsd:choice>
</xsd:complexType>

With this as the "standard", I could then come in and define these in the target namespace or some other namespace:

<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"/>

This means, of course, that pretty much anything is fair game here as long as it follows some XML Schema definition (if it is possible to find that schema, ie. lax). This is also based on my example bastardization of the DSML v.2 specification. I'm still looking at how we could go more directly from the original spec.

Tom Doman

tdoman@novell.com

>>> "Tom Doman" <TDoman@novell.com> 3/31/2003 3:47:27 PM >>>

OK, XML attributes should be avoided anywhere extensibility is desired. On an element, we can specify an xsi:type attribute but obviously cannot on an attribute. Other than that, if the "standard" uses elements that reference a named type, we can extend that type any way we wish and create XML documents that reference the extensions where needed as below.

Tom Doman

tdoman@novell.com

>>> "Tom Doman" <TDoman@novell.com> 3/31/2003 2:37:27 PM >>>

Pardon me while I continue this conversation with myself but I just learned that there *IS* a way to specify in XML document that a given element conforms to a certain schema. You can inform the schema validator that the current element conforms to a derived type rather than the type that would normally be expected. Continuing the example from below, the XML would look something like this (ignoring any envelopes etc.):

...

<dn>

cn=tdoman,ou=ds,ou=dev,o=novell

</dn>

<name>

description

</name>

<value>

XML Schema Neophyte

</value>

</addAdditional>

<name>

title

</name>

</delete>

</modification>

</modifyRequest>

...

So, now we need to go back to the base DSML v.2 definitions and see if they can be extended in this way. It seems like even XML attributes may not cause us as much grief as we had thought. I'll work on it and try to produce an example before tomorrow's conference call.

Tom Doman

tdoman@novell.com

>>> "Tom Doman" <TDoman@novell.com> 3/31/2003 11:44:29 AM >>>

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 not 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="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">

</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

dsml message