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

RE: Instance to Display/Display to Instance Lexical Mappings (was RE: Validation Error Messages)

From: Ryan Tomayko <rtomayko@columbus.rr.com>
Date: Fri, 6 Jul 2001 03:56:57 -0400 (EDT)
To: www-forms@w3.org
Message-ID: <000f01c105f0$838d25c0$7c261841@SPOCK>

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

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