- From: Ryan Tomayko <rtomayko@columbus.rr.com>
- Date: Fri, 6 Jul 2001 03:56:57 -0400 (EDT)
- To: www-forms@w3.org
> 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. Very good example. But even a simple JPEG (forget conversions to GIF/PDF) being submitted in an XML instance requires a lexical conversion. In the display, the gif is a series of 8 bit bytes, but it must be represented as a string of Base64 characters in the XML instance. So, there is a lexical difference between the data residing in the displayed JPEG and the data in the instance, although it's abstract value remains the same. - Ryan > -----Original Message----- > From: www-forms-request@w3.org [mailto:www-forms-request@w3.org]On > Behalf Of John J. Barton > Sent: Thursday, July 05, 2001 11:41 AM > To: ryant@mad.scientist.com; www-forms@w3.org > Subject: Re: Instance to Display/Display to Instance Lexical Mappings > (was RE: Validation Error Messages) > > > 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 Friday, 6 July 2001 04:49:32 UTC