AW: UI representations of data model

Andy,

thanks for your message. The whole binding issue is thought of
the following way:

A UI control binds to an element in the instance. The instance
is an arbitrary XML document instance which holds the form data.
When binding a form control to a datatype defined in the model,
the form authors doesn't directly bind the UI control to the
datatype in the model, but the corresponding element in the
instance. The data model is the schema of the instance, augmented
with XForms-specific properties.

The element in the instance naturally "knows" what his type
definition is, and thus the type constraints apply to values
entered in that UI control.

Further, the Password issue is an interesting one. To be totally
honest, we haven't fully fleshed out the Password case yet. Should
it purely be a UI property, or should the semantic notion of being
a password be captured in the data model? My resentment is that the
group leans toward the latter approach.

In a multiple-page form, where there is a wizard-style form in the
beginning and later a summary page, you want to make sure
that the password is being visually protected both when entered
in the wizard and later shown in the summary. Therefore, it makes
sense that the item in the data model holds the information about
it being a password.

- Sebastian

> -----Ursprüngliche Nachricht-----
> Von: www-forms-request@w3.org [mailto:www-forms-request@w3.org]Im
> Auftrag von Andy Hird
> Gesendet: Monday, October 30, 2000 3:42 AM
> An: www-forms@w3.org
> Betreff: RE: UI representations of data model
>
>
> Teach me to press send without rereading what I was sending.
>
> One point to add to my confusion. If you do include things like hidden and
> multiline attributes in my <input> elements below then its
> assuming knowledge
> of the type of the data item in the model. How do I know
> user_description is a
> string (and not some structured complex type)?
>
> My assumption is that the person writing the UI representation has this
> knowledge. Not sure if thats a good assumption though.
>
> Andy
>
>
> On 30-Oct-2000 Andy Hird wrote:
> > Hi there,
> > I'm currently working on a project which involves me implementing an
> > XForms-like processing engine.
> >
> > I'm interested in a couple of things - the current state of the
> XForms spec.
> > and any work done on the UI parts of the XForm spec (especially
> representing
> > elements in the data model to the user and how current HTML
> Form mappings can
> > be represented using the XForm datamodel and UI split).
> >
> > The current implementation is split into a data model view
> (heavily based on
> > the April working draft but incorparating XML Schema types and
> restraints)
> > and
> > a UI model I came up with (basically multiple page
> representations of data
> > models - a form is a graph of pages with submit buttons being
> directed links
> > between page nodes in the graph - to allow wizard like forms as well as
> > traditional single page forms).
> >
> > What I'm really interested in is how people see the mapping between data
> > model
> > elements and their representation in the UI (and visa versa).
> >
> > For example (using current HTML Forms to get data from a user)
> a string data
> > type is pretty simple - it maps straight onto the current Form <input
> > type="string"> element.
> >
> > But how is <input type="password"> represented in the
> datamodel/UI split? Is
> > the password quality just a UI dependent representation of a
> string or is
> > password ie. something like:
> > <datamodel>
> >
> > <xform:string name="user_password">
> >
> > .....
> >
> > <ui>
> >
> > <input name="user_password" hidden="yes"/>
> >
> > OR:
> >
> > <xform:string name="user_password" secret="yes" encrypt="yes"/>
> >
> > sort of thing?
> >
> > A similar thing happens with multi line strings (<textarea> elements in
> > HTML).
> > Should it be:
> > <xform:string name="user_description"/>
> > ....
> > <input name="user_description" multiline="yes"/>
> >
> > or
> >
> > <datamodel>
> > <xform:string name="user_description" multiline="yes"/> (infact should
> > multiline
> > even need to be specified?)
> >
> > I'm tending towards the former representation in both cases. Both the
> > propertys
> > password and multiline seem like UI dependent issues (although whether
> > a string can be multiline could be a restriction on the string
> data type).
> >
> > Has anyone done any work with this sort of thing? What sort of ideas are
> > people
> > coming up with here?
> >
> > Andy
>

Received on Wednesday, 1 November 2000 16:43:30 UTC