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.):
...
...
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.
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
>>> "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="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