[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [dsml] An augmentability example: DSML v.2 ModifyRequest
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
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.):
...
<modifyReqest> <dn> cn=tdoman,ou=ds,ou=dev,o=novell </dn> <modification xsi:type="mySampleNameSpace:MyAugmentedSampleDSModification"> <addAdditional> <name> description </name> <value> XML Schema Neophyte
</value> </addAdditional> <delete> <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
>>> "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
>>> "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
|
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]