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

Josef, thanks for taking the time to keep us updated on what is currently in
the works. I am anxious to see what will be proposed in the next cut on the
topic of validation messages.

I wanted to add some assumable elaboration to the second part of your
response. Please feel free to correct anything I might botch up in the
following.

> 2) Ryan has, in his example, touched on another interesting
> area: how to define the mapping between XML Schema value space, the
> lexical value in the instance and the display value?
> And: How to define the way back? Some more topics of current discussion.

I am going to concentrate primarily on the instance to display and display
to instance mappings as I am wishfully assuming that the schema to instance
mappings will follow the rules defined in the Schema Recommendation.

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.

For example, if the instance document contains a node associated with an
xsd:date type defined in the model, it must meet the ISO-8601 specification
for date format (e.g. CCYY-MM-DD). However, the XForm designer may prefer to
display the date in some other format, such as MM/DD/CCYY, as well as
require the user to enter values in MM/DD/CCYY format. As such, the lexical
space for the display differs from the lexical space of the instance yet the
value space remains unchanged.

In the preceding example, the lexical space was not only expanded to include
MM/DD/CCYY literal values, it was completely redefined by removing the
CCYY-MM-DD values and replacing them with MM/DD/CCYY values. In essence, the
lexical space of the display may be different than the lexical space of the
instance but the *value* space must remain constant in order to perform
validations and calculations at the instance level.

More examples of instance vs. display lexical spaces:

1. integer types displayed/entered as hex.
2. currency type displayed/entered with currency character (e.g. $)
3. string case conversions for display.
4. time types displayed/entered in local time zone.
5. boolean types displayed/entered as yes/no, on/off, etc..
6. Language of enumerated types. e.g. water, agua, wasser, acqua. (This is a
stretch)

The immediate question in my mind becomes - how do you map values from one
lexical space to values in another lexical space in an extensible yet
non-intrusive manner? The answer to this question will be the answer to:

> how to define the mapping between [snip] the
> lexical value in the instance and the display value?
> And: How to define the way back?

While XML Schema allows existing lexical/value spaces to be restricted, to
my knowledge, it does not define facilities for extending or redefining
lexical spaces associated with a types value space. For example, there is no
way to redefine the lexical space of a boolean type from the XML Schema
defined {true,false} to a custom {yes,no} while maintaining the abstract
value space of {!0,0}.

I regret to say that I don't have any suggestions worth including in this
message. The main intent of this message was to add more detail on this
topic for others.

- Ryan Tomayko
mailto:rtomayko@stercomm.com
Sterling Commerce
www.sterlingcommerce.com


> -----Original Message-----
> From: www-forms-request@w3.org [mailto:www-forms-request@w3.org]On
> Behalf Of Josef Dietl
> Sent: Tuesday, July 03, 2001 10:04 AM
> To: niall@pobox.com; ryant@mad.scientist.com; www-forms@w3.org
> Subject: RE: Validation Error Messages
>
>
> Hi...
>
> The answer to this has two parts:
> 1) such a mechanism is in the works. Probably it's not as elaborate as
> Niall's ideas. After all, we are chartered to deliver XForms
> 1.0 rather
> soon. Still, it's coming, and I look forward to your comments to what
> the group is cooking up.
>
> 2) Ryan has, in his example, touched on another interesting
> area: how to
> define the mapping between XML Schema value space, the
> lexical value in
> the instance and the display value? And: How to define the way back?
> Some more topics of current discussion.
>
> Not particularly helpful, I'm afraid, but hopefully at least
> enlightening :-)
>
> Josef
>
> > -----Original Message-----
> > From: Niall Smart [mailto:regkey@yahoo.com]
> > Sent: Tuesday, July 03, 2001 3:14 PM
> > To: ryant@mad.scientist.com; www-forms@w3.org
> > Subject: Re: Validation Error Messages
> >
> >
> > --- Ryan Tomayko <rtomayko@columbus.rr.com> wrote:
> >
> > > I would like to suggest facilities for attaching a caption
> > or descriptive
> > > message to data model validation or individual ui controls.
> > In essence, the
> > > message would describe the validation error that occured.
> > This is necessary
> > > if a descriptive message is to be given to the user when a
> > field fails
> > > validation.
> >
> > I had also been thinking about this, but came up with a
> > different model to
> > the one you are proposing.  My approach allows different
> > messages to be
> > displayed depending on which facet has not been complied
> > with.  For example,
> > given this model:
> >
> > <model>
> >     <date name="startDate" required="true" max="endDate">
> >     <date name="endDate" required="true" min="startDate">
> > </model>
> >
> > then the error messages would be associated with the model using the
> > following syntax:
> >
> > <messages locale="EN">
> >     <startDate>
> >         <required>You must enter a start date.</required>
> >         <max>The start date must be before the end date.</max>
> >     </startDate>
> >     <endDate>
> >         <required>You must enter an end date.</required>
> >         <min>The end date must be after the start date.</max>
> >     </endDate>
> >
> >     <required>You have not entered a mandatory field.</required>
> > </messages>
> >
> > In the event of a facet f on model item with path p not
> being complied
> > with then the processor will search for
> >
> >     messages[@locale=getlocale()]/p/f
> >
> > If this is not found then the last path element of p will
> be stripped
> > off and it will try again, this allows "catch-all" error messages to
> > be specified as above.
> >
> > Comments?
> >
> > Niall
> >
> >
> > ____________________________________________________________
> > Do You Yahoo!?
> > Get your free @yahoo.co.uk address at http://mail.yahoo.co.uk
> > or your free @yahoo.ie address at http://mail.yahoo.ie
> >
> >
>

Received on Wednesday, 4 July 2001 02:29:31 UTC