RE: How to change the order of repeat-items?

Sorting on the UI side for select1 makes a lot of sense and I have a use
case for it.
I could go either way on repeat, though (model or UI).

Ben's suggestion of sort-key="@surname, @firstname" seems like a good
start but I have two concerns:
1. Comma separated attribute list, even if space separated.
2. The sort keys and ordering are fixed and cannot be altered by UI
operations.

As Raman points out below, most cases for sortable lists have multiple
sort columns, allow them to be selected, and allow the
ascending/descending sort to be specified by UI operations.  (Again,
look at your mail reader.)

How about adding sort and orderby elements as children of itemset?  Then
you can use @ref or @value on them to gain at least one level of
indirection, and to fit in more harmoniously with the existing features
of itemset.

<select ref="destination">
  <itemset nodeset="instance('oag')/airports">
    <label ref="@name" />
    <value ref="." />
    <sort ref="@name" />
    <orderby>ascending</orderby>
  </itemset>
</select>

Unfortunately, that still provides only a single sort, and doesn't offer
a way to describe to the UI the alternatives to choose from.
Might switch might come to the rescue here?  (Again, that seems
problematic as it would be inside a repeating structure.)
Does anyone want to take it from here?  (Sorry for the partly-baked
idea.)

Leigh.

-----Original Message-----
From: T. V. Raman [mailto:tvraman@us.ibm.com] 
Sent: Saturday, April 16, 2005 8:34 AM
To: Ben.Atfield@x-port.net
Cc: tvraman@almaden.ibm.com; Klotz, Leigh;
suzan.foster@nerocmediaware.nl; www-forms@w3.org
Subject: RE: How to change the order of repeat-items?



this is a good summary, Thanks.

I think we should think carefully about re-ordering on the UI side
without sorting things in the data layer; there are pros and cons to
doing that.

It would be simplest to keep the UI reflecting the stte of the data
model, which is why I suggested sorting the data.

The XSLT route would also be easy to try in current browsers most of
which support XSLT through the XSLTProc scripting function; incidentally
this is what GoogleMaps uses in both IE and Mozilla, which is also one
of the reasons GoogleMaps fails in back-level browsers like Opera that
do not understand XPath, leave alone XSLT.

So as a first step in figuring out the use cases that we need to
support, I'd suggest experimenting in IE Formsplayer and FireFox XForms
by implementing the sort via XSLT called through XSLTProc to rearrange
the nodes in the instance.

Here are some of the sort use cases I've seen on the Web  today:

a) Phone bills; allow you to sort the list of calls according to various
criteria

B) Shopping sites of course.

In general sort today shows up in grid layouts achieved via scripting,
but a more interesting use case that doesn't show up on today's Web
mostly due to the limitations of what has been possible is dynamic
sorting of deeply nested structured data whereby things of interest
bubble to to the top of the tree as the user specifies some input.

As an example, consider a collection of all  airports in the world
organized as a structured tree. Navigating this tree
typically would take a   sequence of interaction gestures to open
up multiple levels of the tree.
You can implement nested tree navigation as has already been shown by
Mark Birbeck in FormsPlayer; it would be interesting to first lash
together the ability to sort the data nodes using XSLT
--- and having that functionality in place, start doing some
experimentation on the above tree navigation example to see if we could
speed up task completion by sorting as the user types i.e. the
equivalent of Emacs incremental search with the effect showing up on the
display by the tree reforming itself to reflect the items to be most
likely of interest.

The best thing about all this is that with what we have in place, a
chunk of experimentation can be done before any spec writing.

>>>>> "Ben" == Ben Atfield <Ben.Atfield@x-port.net> writes:
    Ben> Raman/Leigh/Suzan,
    >> An interesting place to start this investigation would be
    >> to see if exslt.org has already gone down this (x)path of
    >> sorting nodes.
    Ben> 
    Ben> EXSLT.org wouldn't need to, since XSLT itself supports
    Ben> sorting. As Leigh says, though, the XSLT way, may be the
    Ben> model to look at (see later). First, it might be worth
    Ben> separating out where we want to do the sorting --
    Ben> establishing the use cases.
    Ben> 
    Ben> If we want a xf:repeat that behaves like a grid, and
    Ben> (for example) clicking on the heading of a column sorts
    Ben> by that column, this actually has nothing to do with the
    Ben> XForms model, and only relates to the UI. A UI could
    Ben> support this feature *now* without requiring any changes
    Ben> to XForms.
    Ben> 
    Ben> Similarly, if you want to sort the nodes in a nodeset --
    Ben> actually re-order them, not just render them differently
    Ben> -- then that can be achieved *now* with an extension
    Ben> function (most implementations support the definition of
    Ben> extra functions that are not part of the base spec).
    Ben> 
    Ben> Whilst these use cases can be done now, there are of
    Ben> course others that can't. The main one is where the
    Ben> *author* wants the UI to render data in a certain order,
    Ben> independently of how the user might interact with that
    Ben> data, and also independently of the order of the
    Ben> instance data.
    Ben> 
    Ben> The two situations where this might be the case would be
    Ben> the 'choices' in an xf:itemset (in xf:select1 and
    Ben> xf:select), and of course a list of items in a
    Ben> xf:repeat.
    Ben> 
    Ben> A simple solution would be to take attributes much like
    Ben> those used in XSLT [1] -- as alluded to by Leigh -- and
    Ben> allow them anywhere that @nodeset is allowed. For
    Ben> example:
    Ben> 
    Ben>   <xf:instance> <countries xmlns="" cur=""> <country
    Ben> id="10" name="USA" /> <country id="20" name="UK" />
    Ben> <country id="30" name="France" /> </countries>
    Ben> </xf:instance>
    Ben> 
    Ben>   <xf:select1 ref="@cur"> <xf:label>Choose
    Ben> country:</xf:label> <xf:itemset nodeset="country"
    Ben> sort-key="@name" order="descending"> <xf:label
    Ben> ref="@name" /> <xf:value ref="@id" /> </xf:itemset>
    Ben> </xf:select1>
    Ben> 
    Ben> Output: ___________ Choose country: [___________] V |
    Ben> USA | | UK | | France | |___________|
    Ben>  
    Ben> 
    Ben> By allowing these attributes to operate alongside
    Ben> @nodeset, they would also be available to xf:bind and
    Ben> xf:repeat, too.
    Ben> 
    Ben> However, the obvious next issue would be how to sort by
    Ben> two (or more) columns. For that we'd probably want to
    Ben> make each attribute a list:
    Ben> 
    Ben>   <xf:instance> <people xmlns=""> <person id="10"
    Ben> firstname="Leigh" surname="Klotz" /> <person id="20"
    Ben> firstname="Suzan" surname="Foster" /> <person id="10"
    Ben> firstname="T V" surname="Raman" /> </people>
    Ben> </xf:instance>
    Ben> 
    Ben>   <xf:repeat nodeset="person" sort-key="@surname,
    Ben> @firstname"> <xf:output value="concat(@surname, ', ',
    Ben> @firstname)" /> </xf:repeat>
    Ben> 
    Ben> Output:
    Ben> 
    Ben>   Foster, Suzan Klotz, Leigh Raman, T V
    Ben> 
    Ben> The alternative of using the XSLT approach (specifying
    Ben> the sort order with child elements) could be done, but
    Ben> might get a little tricky to define clearly, given that
    Ben> xf:repeat actually contains the template that is to be
    Ben> repeated:
    Ben> 
    Ben>   <xf:repeat nodeset="person"> <xf:sort
    Ben> select="@surname" /> <xf:sort select="@firstname" />
    Ben> <xf:output value="concat(@surname, ', ', @firstname)" />
    Ben> </xf:repeat>
    Ben> 
    Ben> Anyway, my main point is that there are plenty of things
    Ben> that can be done now, without changing the XForms spec,
    Ben> and still producing interoperable forms. However, there
    Ben> are definitely situations were we need something more
    Ben> than that.
    Ben> 
    Ben> Regards,
    Ben> 
    Ben> Mark
    Ben> 
    Ben> 
    Ben> [1] <http://www.w3.org/TR/xslt.html#sorting>
    Ben> 
    Ben> Mark Birbeck CEO x-port.net Ltd.
    Ben> 
    Ben> e: Mark.Birbeck@x-port.net t: +44 (0) 20 7689 9232 w:
    Ben> http://www.formsPlayer.com/ b:
    Ben> http://internet-apps.blogspot.com/
    Ben> 
    Ben> Download our XForms processor from
    Ben> http://www.formsPlayer.com/
    Ben> 
    Ben> 

--
Best Regards,
--raman
------------------------------------------------------------
T. V. Raman:  PhD (Cornell University)
IBM Research: Human Language Technologies
Architect:    RDC --- Conversational And Multimodal WWW Standards
Phone:        1 (408) 927 2608   T-Line 457-2608
Fax:        1 (408) 927 3012     Cell: 1 650 799 5724
Email:        tvraman@us.ibm.com
WWW:      http://almaden.ibm.com/u/tvraman      (google:raman+labrador)
AIM:      emacspeak
GPG:
http://www.almaden.ibm.com/cs/people/tvraman/raman-almaden.asc
Snail:        IBM Almaden Research Center,
              650 Harry Road
              San Jose 95120

Received on Monday, 18 April 2005 17:26:23 UTC