W3C home > Mailing lists > Public > www-forms@w3.org > August 2000

Data Model vs. Data Validation

From: T. V. Raman <tvraman@almaden.ibm.com>
Date: Fri, 25 Aug 2000 11:35:34 -0700 (PDT)
Message-ID: <14758.48246.181197.797909@raman.almaden.ibm.com>
To: www-forms-request@w3.org
Cc: "XForms" <www-forms@w3.org>
This is a good set of questions and reflects the classic
"one man's type is another man's constraint.".

The way we are thinking about the data model in XForms at
present is that it encapsulates 
two "classes" of information 
1) information necessary for classic static type checking  
2) runtime dynamic constraints that further narrow the
constraints from static type checking described in (1).

The balance between 1 and 2 is  what is raised in this

I beleive there is no single "right answer"
to where types stop  and constraints being--

>>>>> "www-forms-request" == www-forms-request  <www-forms-request@w3.org> writes:

    www-forms-request> I have spent the last year and a half
    www-forms-request> building a proprietary architecture
    www-forms-request> which shares many design goals with
    www-forms-request> XForms.  Our system is written in
    www-forms-request> Java and uses XML bindings for
    www-forms-request> constructing controls and validations
    www-forms-request> upon them.  So naturally, when I
    www-forms-request> learned of XForms a few months ago, I
    www-forms-request> became very interested.  I would
    www-forms-request> naturally like to take advantage of
    www-forms-request> the synergy and migrate our system to
    www-forms-request> track the specification.  I have
    www-forms-request> recently started to take a closer
    www-forms-request> look at just how I would do this, and
    www-forms-request> it has raised some concerns.

    www-forms-request> It is stated that XForms will be
    www-forms-request> split into three layers, Data, Logic,
    www-forms-request> and Presentation.  Naturally I think
    www-forms-request> this is fantastic.

    www-forms-request> My issue is that there seems to be no
    www-forms-request> distinction/separation between the
    www-forms-request> "Data Model" and the "Validation"
    www-forms-request> upon that model.  These are decidedly
    www-forms-request> different concepts and should be
    www-forms-request> separated out.  I would argue that
    www-forms-request> these validations should be part of
    www-forms-request> the "Logic" (or some other?) layer,
    www-forms-request> rather than the part of the data
    www-forms-request> model itself.

    www-forms-request> <number name="count" min="1"
    www-forms-request> integer="true"/>

    www-forms-request> It is up to the data model to specify
    www-forms-request> how one defines a number, as above.
    www-forms-request> An attributes such as "min" is not
    www-forms-request> part of the data model, it is at a
    www-forms-request> higher level.  The "min" attribute
    www-forms-request> works /with/ a number..."min" in no
    www-forms-request> way actually defines what you are
    www-forms-request> working with /as/ a number.

    www-forms-request> The data model should be just that, a
    www-forms-request> data model...it should restrict
    www-forms-request> itself to defining the datatypes.
    www-forms-request> This can be a fine line.  I don't
    www-forms-request> think masking, for example, is a
    www-forms-request> validation...I view a mask the same
    www-forms-request> way I do the "integer" attribute
    www-forms-request> above...as 'subclassing' a general
    www-forms-request> type into a more specific type.  For
    www-forms-request> example, I would view a phone number
    www-forms-request> mask as /defining/ the pattern of
    www-forms-request> digits that constitutes a phone
    www-forms-request> number...a validation would be
    www-forms-request> something that says something like
    www-forms-request> "the area code must be 204"..it works
    www-forms-request> /with/ the phone number, but does not
    www-forms-request> define what a phone number is, and
    www-forms-request> should thus be separate.

    www-forms-request> Mixing data and validation leads to
    www-forms-request> problems later on when you want to
    www-forms-request> add more (complex) validations.  I
    www-forms-request> initially made the same mistake in
    www-forms-request> the system I built.  I have to deal
    www-forms-request> with validation such as "If the user
    www-forms-request> selects 'item 1' from the 'droplist
    www-forms-request> field', the 'number field' must be
    www-forms-request> 'between 1 and 5'.  If they select
    www-forms-request> 'item 2' from the list, the number
    www-forms-request> must be between '6 and 10', etc,
    www-forms-request> etc".  I quickly got to the point
    www-forms-request> where the form author needed the
    www-forms-request> ability to add custom form specific
    www-forms-request> validations.  At this point is where
    www-forms-request> you start to see the need for an
    www-forms-request> independent and extensible way to
    www-forms-request> define validations.  And the best
    www-forms-request> thing of all...we already have a
    www-forms-request> basis for this...it's called
    www-forms-request> MathML....

    www-forms-request> For the above number example:

    www-forms-request> <apply> <min/> <ci>count</ci>
    www-forms-request> <cn>1</cn> </apply>

    www-forms-request> or instead of:

    www-forms-request> <string name="foo" min="5"/>

    www-forms-request> you could:

    www-forms-request> <apply> <min/> <apply> <strlen/>
    www-forms-request> <ci>foo</ci> </apply> <cn>5</cn>
    www-forms-request> </apply>

    www-forms-request> Doing things like this allows one to
    www-forms-request> build significantly more complex
    www-forms-request> validations...and you can create
    www-forms-request> custom ones just as you create custom
    www-forms-request> functions in MathML.

    www-forms-request> --- Chris Hubick
    www-forms-request> mailto:chris@hubick.com
    www-forms-request> http://www.hubick.com/

Best Regards,

IBM Research: Human Language Technologies
Phone:        1 (408) 927 2608
Fax:        1 (408) 927 3012
Email:        tvraman@us.ibm.com
WWW:      http://www.cs.cornell.edu/home/raman
PGP:          http://cs.cornell.edu/home/raman/raman.asc 
Snail:        IBM Almaden Research Center,
              650 Harry Road
              San Jose 95120
Received on Friday, 25 August 2000 14:37:03 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:36:03 UTC