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

Yes, classical XML require base64 encoding of binary data.
However XML has URL refs and these refs can be internal to
messages.  For this reason I worked on a proposal to standardize
the MIME packaging of XMLP and binary data in its un-encoded
form.  See
http://www.w3.org/TR/SOAP-attachments
The same approach can be used for non XMLP XML.  This approach
would be a nice one for XFORMs POST.

This doesn't change your main point that wire formats, server
formats, and client formats are unlikely to be identical.

John.

At 03:56 AM 7/6/2001 -0400, Ryan Tomayko wrote:

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

______________________________________________________
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 13:03:43 UTC