- 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 UTC