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
undesirable.
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"/>
</AttributeDef>
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"/>
</AttributeDef>
Nested ValidIf tags are ANDed (somewhat like nested if)
<AttributeDef Name="ByteValue" Datatype="int">
<ValidIf rule="GreaterOrEqual" value="0">
<ValidIf rule="LessOrEqual" value="255"/>
</ValidIf>
</AttributeDef>
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"/>
</AttributeDef>
Actually, by making "Equals" the default rule, we have
<AttributeDef Name="Colour" Datatype="string">
<ValidIf value="Red"/>
<ValidIf value="Green"/>
<ValidIf value="Blue"/>
</AttributeDef>
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
-----
Olivo Miotto Technology Expert (Distributed Object Computing)
Institute of Systems Science, National University of Singapore
olivo@iss.nus.edu.sg Tel: +65-772 6644 Fax: +65-778 2571