- From: Chris Hubick <chris@hubick.com>
- Date: Fri, 25 Aug 2000 11:23:36 -0400
- To: "XForms" <www-forms@w3.org>
I have spent the last year and a half building a proprietary architecture which shares many design goals with XForms. Our system is written in Java and uses XML bindings for constructing controls and validations upon them. So naturally, when I learned of XForms a few months ago, I became very interested. I would naturally like to take advantage of the synergy and migrate our system to track the specification. I have recently started to take a closer look at just how I would do this, and it has raised some concerns. It is stated that XForms will be split into three layers, Data, Logic, and Presentation. Naturally I think this is fantastic. My issue is that there seems to be no distinction/separation between the "Data Model" and the "Validation" upon that model. These are decidedly different concepts and should be separated out. I would argue that these validations should be part of the "Logic" (or some other?) layer, rather than the part of the data model itself. <number name="count" min="1" integer="true"/> It is up to the data model to specify how one defines a number, as above. An attributes such as "min" is not part of the data model, it is at a higher level. The "min" attribute works /with/ a number..."min" in no way actually defines what you are working with /as/ a number. The data model should be just that, a data model...it should restrict itself to defining the datatypes. This can be a fine line. I don't think masking, for example, is a validation...I view a mask the same way I do the "integer" attribute above...as 'subclassing' a general type into a more specific type. For example, I would view a phone number mask as /defining/ the pattern of digits that constitutes a phone number...a validation would be something that says something like "the area code must be 204"..it works /with/ the phone number, but does not define what a phone number is, and should thus be separate. Mixing data and validation leads to problems later on when you want to add more (complex) validations. I initially made the same mistake in the system I built. I have to deal with validation such as "If the user selects 'item 1' from the 'droplist field', the 'number field' must be 'between 1 and 5'. If they select 'item 2' from the list, the number must be between '6 and 10', etc, etc". I quickly got to the point where the form author needed the ability to add custom form specific validations. At this point is where you start to see the need for an independent and extensible way to define validations. And the best thing of all...we already have a basis for this...it's called MathML.... For the above number example: <apply> <min/> <ci>count</ci> <cn>1</cn> </apply> or instead of: <string name="foo" min="5"/> you could: <apply> <min/> <apply> <strlen/> <ci>foo</ci> </apply> <cn>5</cn> </apply> Doing things like this allows one to build significantly more complex validations...and you can create custom ones just as you create custom functions in MathML. --- Chris Hubick mailto:chris@hubick.com http://www.hubick.com/
Received on Friday, 25 August 2000 11:23:34 UTC