Re: positional predicates in canonical binding-expressions?

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 
<person>
<first>joe</first>
<last>turner</last>
</person>
 and not 
<person>
<last>turner</last>
<first>joe</first>
</person>

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

selectMany:
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
either:

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

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

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