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

Re: positional predicates in canonical binding-expressions?

From: T. V. Raman <tvraman@almaden.ibm.com>
Date: Fri, 13 Jul 2001 08:47:02 -0700
Message-ID: <15183.6134.166677.24376@bubbles.almaden.ibm.com>
To: joern turner <joern.turner@web.de>
Cc: tvraman@almaden.ibm.com, www-forms@w3.org
Returning to the issue of "ordering"

the ordering you get today on the WWW with HTML select
multiple is mostly accidental --it's just that the common
case works as expected.

Ideally I'd like to set XForms up   in a similar manner
without adding too much baggage --
given this, 
and assuming that document order was preserved, I believe
that both selectMany and repeat as specified should not
yield any surprizes.

An application that really really wanted to insist that the
user only submit 
 and not 

could assert that  using the schema.
So in the repeat/selectMany case,
where this order is not insisted upon by the validation--
here is what might be expected to happen:

Instance gets created at init time --there is an XML tree
now capable of holding what the user selects using the
controls --

User checks third item --then the first item -- and then the
fourth item from a list of 10 choices.

Depending on how the processing model is set up we could

A) capture the order in which he selected things 
B) Capture the selections in the order in which they appear
in the model --hence the presentation--

I'd suggest (B)  
it preserves document order --and leads to the least amount
of surprize.

A more sophisticated application that wanted to let the user
rank his choices,
would have to do something smarter than use a vanila

In summary, selectMany populates a "set" --and "sets" are
unordered collections for the very reason shown above.

Similar reasoning for repeat.show above.

>>>>> "joern" == joern turner <joern.turner@web.de> writes:

    joern> Hello, before starting i should state that i'm
    joern> really welcome the work about the
    joern> repeat-element. this solves a contiuous and
    joern> repeating ;) problem especially in web
    joern> form-processing.

    joern> from my understanding of the draft, the structure
    joern> of the instance can be constructed without
    joern> referring to a schema - simply by extracting this
    joern> information out of the binding-expression used in
    joern> the XForms UI. if this is not right, some or all
    joern> of the following may be irrelevant.

    joern> T. V. Raman wrote:

    >> Hi -- you're correct in that there is no way to
    >> reassemble a list of items on the server because of
    >> how WWW form post works today.
    >> However there is nothing inside the specification for
    >> repeat that claims we preserve order --perhaps we
    >> should make it even clearer.

    joern> Yes, you're right. That was just an assumption i
    joern> silently made. But, would'nt the user expect to
    joern> get the data back in the order they have been
    joern> inputted? Wouldn't the notion of a 'document
    joern> order' as it is common in XML be destroyed?

    joern> second, -- assuming you have a list of lists in
    joern> your instance-data which you use as initial data
    joern> (presets) or a preloaded instance, it is not
    joern> possible to reconstruct this list in a submit
    joern> without the usage of positional predicates. The
    joern> result (again the example from the draft) would
    joern> simply be:

    joern> <items> <item> <f1>first</f1> <f2>first</fi>
    joern> <f1>second</f1> <f2>second</f2> <f1>third</f1>
    joern> <f2>third</f2> </item> </items>

    joern> which is clearly a different semantic. maybe i'm
    joern> on the wrong track here, but i'm using the
    joern> algorithm which is described for
    joern> instance-initialization: evaluating the binding
    joern> expression from left to right and creating
    joern> appropriate children for each step, if it does
    joern> not exist already.  although the brilliant
    joern> simplicity of that algorithm would get
    joern> complicated by positions, i couldn't think of any
    joern> other way to preserve the input order which i (as
    joern> you might have guessed by now) consider essential
    joern> for the usefullness of repeat. otherwise i would
    joern> urge the application using the XForms processor
    joern> to achieve this some way - which may be
    joern> complicated.

    >> Incidentally I'm surprized you raised this in
    >> connection with repeat --and not selectMany --both
    >> have the same problem --only difference is that
    >> selectMany is populating a schema list --repeat is
    >> populating something with more substructure

    joern> not exactly. - a selectMany (in html e.g. mapped
    joern> to a <select multiple="true" ...) will be send as
    joern> a single parameter: with parameter-name and an
    joern> array of values. The selected values occur in the
    joern> order they're displayed in the list. - at least
    joern> when you're using the serlvet-api to parse
    joern> parameters.

    joern> please excuse my lengthy explanations but as i
    joern> can hardly think of an application which does not
    joern> rely on some kind of 'natural' order, this seems
    joern> to be an important topic to me.


Best Regards,

IBM Research: Human Language Technologies
Phone:        1 (408) 927 2608
Fax:        1 (408) 927 3012
Email:        tvraman@us.ibm.com
WWW:      http://www.cs.cornell.edu/home/raman
PGP:          http://emacspeak.sf.net/raman.asc
Snail:        IBM Almaden Research Center,
              650 Harry Road
              San Jose 95120
Received on Friday, 13 July 2001 11:48:53 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:36:04 UTC