- From: John J. Barton <John_Barton@hpl.hp.com>
- Date: Thu, 05 Jul 2001 08:41:06 -0700
- To: <ryant@mad.scientist.com>, <www-forms@w3.org>
At 02:23 AM 7/4/2001 -0400, Ryan Tomayko wrote: >The general situation seems to be that data residing in the instance might >require some formatting before being rendered to the display, and data >entered by the user might need to take some other form before being placed >into the instance. In more complex terms, the lexical space of a model >defined type may need expanded, or redefined, to allow for different literal >values targeting the display. Ryan followed up with a series of examples like hex<->int. These seem easy enough to handle in the client, but their inclusion in their many kinds will continue the seemingly boundless expansion of resource requirements for client. As an alternative, consider examples that are structurally similar but seemingly too complex to require in clients, such as forms that require JPEG inputs but clients only have PDF, GIF, or some such. So maybe you don't care about these, but it does show that the line will have to be drawn somewhere arbitrarily. (E. Kiciman at Stanford has work on automatic concatenation of transformations for such conversions). Thus the alternative: explore a solution that is server centric or rather that is based on content-negotiation. The form says "give me a number between 0-255, like 0xFF". The client says "14". The server says "hmmm...ok I understand decimal to hex, thank you", or it says "huh? whatzat?". This kind of approach allows attempted fill-in for more kinds of clients and expansion of capabilities on either end of the wire. John. ______________________________________________________ John J. Barton email: John_Barton@hpl.hp.com http://www.hpl.hp.com/personal/John_Barton/index.htm MS 1U-17 Hewlett-Packard Labs 1501 Page Mill Road phone: (650)-236-2888 Palo Alto CA 94304-1126 FAX: (650)-857-5100
Received on Thursday, 5 July 2001 11:44:14 UTC