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

RE: Xforms 1.0 data model

From: Bruce Williams <brucewil@pacbell.net>
Date: Fri, 07 Jul 2000 20:29:21 -0700
To: Rob McDougall <RMcDouga@JetForm.com>, www-forms@w3.org
Message-id: <NDBBIDFMJLFLLJLCEBKMKELNCOAA.brucewil@pacbell.net>
Possibly this is an issue that also could interact with web accessibility?

Anyone interested in the W3 guidelines in this area may find more info at:

http://www.w3.org/WAI/

http://www.w3.org/WAI/Reference

http://www.w3.org/TR/WAI-WEBCONTENT/

I would also be happy to refer anyone to people who are -clued- in this
area. It is an overlooked issue, but disabled access and mobile, etc
overlap. There is a possibility that Xforms and other new standards could
support an application-independant accessibility that is beyond the wildest
dreams of the the disabled.

Best wishes,

Bruce Williams

 "One should never increase, beyond what is necessary, the number of
entities required to explain anything". William of Ockham (1285-1349)



  -----Original Message-----
  From: www-forms-request@w3.org [mailto:www-forms-request@w3.org]On Behalf
Of Rob McDougall
  Sent: Friday, July 07, 2000 1:24 PM
  To: www-forms@w3.org
  Subject: RE: Xforms 1.0 data model


  Chris,

  Thank you for your input.

  We've looked at the requirement to have user-defined (i.e. "custom")
datatypes and are still grappling with the issue.  There are two fundamental
questions:

  1) Should we have user-defined datatypes?
  Pro:  They make the datamodel easier to use and more expressive
  Con: They ratchet up the complexity of building an XForms client and may
alienate implementers targeting smaller devices

  2) Once a user has defined a new type, how should it be referenced, as an
element name or via an attribute name?  Your example uses an element name.
  Pro: Element names are more concise and generally regarded as "simpler"
  Con: Using an element name means the grammar cannot be described by an XML
Schema without performing a transformation first.

  These are not easy trade-offs to make, but I expect you'll probably see
some decisions in the next working draft (no I can't say when that will be).

  Regards,
  Rob

    -----Original Message-----
    From: Chris Judge [mailto:chris@formfill.com]
    Sent: July 6, 2000 5:06 PM
    To: www-forms@w3.org
    Cc: mdubinko@cardiff.com; ssilvester@cardiff.com; schnitz@overflow.de;
dsr@w3.org
    Subject: Xforms 1.0 data model


    Hi all:



    In reviewing the XForms 1.0 Data Model (working draft 06 April 2000), I
noticed that several of the issues concern methods for reducing redundancy.
For example, section 4.4 (Monetary Values), states:



    [Issue: Do we want to support a means to indirectly specify facets when
there are many money values in a form, all of which accept the same
currency?]




    A simple solution would be to define a new element in the <model>
section which defines custom data types. For example:



    ...

    <model>

    <custom name="USDollars" type="money" currency="USD" min="0"
digits="2"/>

    <custom name="phonenumber" type="string" mask="ddd?ddd-dddd"/>

    <group name="customer">

    <string name="name"/>

    ...

    <phonenumber name="voice"/>

    <phonenumber name="fax"/>

    <USDollars name="balancedue"/>

    <USDollars name="taxrate" digits="4"/>

    ....

    </group>

    </model>



    In the above example, "voice" and "fax" are both string data elements
and "balancedue" and "taxrate" are both money elements. Note also that
"taxrate" overrides the "digits" value defined in USDollars.



    The example should make it clear that a <custom> element can be used to
define a template for any of the pre-defined data elements.



    Finally, it would be easy to include scoping rules so that a <custom>
element defined within a <group> will only be available within that <group>.



    Thanks for your time and if I'm mailing these suggestions to the wrong
people, please let me know.





    Chris Judge,

    FormFill, Inc.

    (512) 419-0304
Received on Friday, 7 July 2000 23:47:10 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Saturday, 10 March 2012 06:21:48 GMT