Datatype constraints in DCDs

Olivo Miotto olivo at
Fri Oct 9 03:15:10 BST 1998

I've been through the note with Dean Roddey's proposal for constraint
formulation (,
and I think it's on the right track.

It seems that some of the concerns voiced in its replies are justified
though, in particular the use of an additional parsing mechanism. I
think XML parsing should be used.

Dean offers an extensible mechanism, which is good; the alternatives
proposed would create a number of additional tags which seems

Lastly, his concerns about the readability of the DCD I think are
good, but on one hand this type of constraint building may be more
interesting for non-human readable files; on the other, I feel the
readability is impaired by the And/Or constructs in his proposal.

I have thought about it, and believe that a more "slimline"
solution would be to introduce a single <IsValid> tag, which
works as an "if" statement, as follows

<AttributeDef Name="Age" Datatype="int">
    <ValidIf rule="GreaterOrEqual" value="0"/>

Several ValidIf tags in sequence are ORed (somewhat like if...elseif)

<AttributeDef Name="Value" Datatype="int">
    <ValidIf rule="LessThan" value="0"/>
    <ValidIf rule="GreaterThan" value="255"/>

Nested ValidIf tags are ANDed (somewhat like nested if)

<AttributeDef Name="ByteValue" Datatype="int">
    <ValidIf rule="GreaterOrEqual" value="0">
        <ValidIf rule="LessOrEqual" value="255"/>

Specifying an enumeration may be simply done as follows

<AttributeDef Name="Colour" Datatype="string">
    <ValidIf rule="Equals" value="Red"/>
    <ValidIf rule="Equals" value="Green"/>
    <ValidIf rule="Equals" value="Blue"/>

Actually, by making "Equals" the default rule, we have

<AttributeDef Name="Colour" Datatype="string">
    <ValidIf value="Red"/>
    <ValidIf value="Green"/>
    <ValidIf value="Blue"/>

which does away with the <Values> tag which I though was
a little grotty.

This is the definition of the tag

<!ELEMENT ValidIf        (ValidIf)*>
<!ATTLIST ValidIf   rule CDATA           "Equals"
                    value     CDATA           #IMPLIED>

The rule attribute is left as CDATA to allow for custom
validation rules. An initial simple set may be

     Equals    LessThan  LessOrEqual
     NotEquals GreaterThan    GreaterOrEqual

(or EQ, NE, LT, LE, GT, GE which seem sufficiently commonly
understood). Because of the stronger typing given by the
Datatype parameter, I believe there is no need for separate
operators for string and numerals.

A number of operators may be added, such as "MultipleOf", or
"BeginsWith" or "Contains" etc. but I would propose keeping
the basic set simple. I think the basic operators above would
cover the majority of cases, especially if you remember that
the objective is to describe the data constaints, not to test
arbitrary data.

I haven't thought a lot about it, but I believe this could
accomodate operators like "IsNull" or "IsNotNull" (without
value attribute), important to RDBMS folks.

Well, that's it. I think this would clean up a lot of the
datatype-related bits that are crowding the element and
attribute definitions in DCD. I hope I have not overlooked
anything. Look forward to your comments.


Olivo Miotto            Technology Expert (Distributed Object Computing)
Institute of Systems Science, National University of Singapore
olivo at    Tel: +65-772 6644       Fax: +65-778 2571

xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev at
Archived as:
To (un)subscribe, mailto:majordomo at the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo at the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa at

More information about the Xml-dev mailing list