- From: T. V. Raman <tvraman@almaden.ibm.com>
- Date: Fri, 25 Aug 2000 11:35:34 -0700 (PDT)
- To: www-forms-request@w3.org
- Cc: "XForms" <www-forms@w3.org>
This is a good set of questions and reflects the classic
problem
"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
message.
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,
--raman
------------------------------------------------------------
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