[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: An augmentability example: DSML v.2 ModifyRequest
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
|
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]