W3C home > Mailing lists > Public > www-forms@w3.org > March 2007

Re: Last call comment: XForms 1.1 is missing a string compare capability

From: Roland Merrick <roland_merrick@uk.ibm.com>
Date: Sat, 10 Mar 2007 09:24:17 +0000
To: John Boyer <boyerj@ca.ibm.com>
Cc: www-forms@w3.org, www-forms-editor@w3.org, www-forms-editor-request@w3.org
Message-ID: <OFC8DB4711.2F3D169B-ON8025729A.0032F0F4-8025729A.0033A7BF@uk.ibm.com>
Greetings John, I assume that the comparison that you are suggesting is to 
order the data for the benefit of the user. In this case "adding a simple 
string-compare() function" is anything but easy. Collating data so that is 
honours language and country conventions for the user is not a "simple" 
exercise.

Regards, Roland



John Boyer <boyerj@ca.ibm.com> 
Sent by: www-forms-editor-request@w3.org
09/03/2007 21:46

To
www-forms-editor@w3.org
cc
www-forms@w3.org
Subject
Last call comment: XForms 1.1 is missing a string compare capability







1.1 has a requirement to allow search for data by a key value.  Although 
the detail text doesn't strictly mention it, I expected that our addition 
of the while attribute to XForms actions allowed us to do a search of 
where to put a new piece of data, and the required improvments to insert 
then allowed us to put it there. 

We can do this if the "key" is a number, but due to a limitation of XPath 
that I think we did not really note until recently, we cannot do the same 
if the key data is a string such as a name.  This means it is not possible 
for an XForm to maintain the ordered nature of a list of data under insert 
mutation.   

This is a trivially obvious use case that I *thought* we were accounting 
for, and it is easily solved by adding a string-compare() function to the 
XForms function library for XPath, and it should be easy to define it to 
be compatible with string comparison available in XPath 2.0. 

Some have complained that since XPath 2 has this, then the right answer is 
to adopt XPath 2.  In principle and in an ideal world, sure we'd get right 
on that, but we should not leave such a gaping hole in XForms 1.1, which 
is still based on XPath 1.0.  Since XPath 1.0 already contains the desired 
feature (the extensibility to allow us to define the function we need), 
there should be nothing wrong with using that feature, esp. if we define a 
compatible function for later upward mobility.  The argument that we 
shouldn't use the XPath 1.0 feature of extensibility because XPath 2 has 
this piece of overlapping functionality is problematic because the 
following conclusion is that we should not add anything since it might 
conflict with XPath 3.0.  If you think this can't happen, observe that it 
already has-- the if() function we desperately needed now conflicts with 
XPath 2.0. 

Conclusion: Please solve the problem that we can only maintain ordered 
numeric data and not ordered string data by adding a simple 
string-compare() function. 

Thanks, 
John M. Boyer, Ph.D.
STSM: Workplace Forms Architect and Researcher
Co-Chair, W3C Forms Working Group
Workplace, Portal and Collaboration Software
IBM Victoria Software Lab
E-Mail: boyerj@ca.ibm.com 

Blog: http://www.ibm.com/developerworks/blogs/page/JohnBoyer







Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 
741598. 
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
Received on Saturday, 10 March 2007 09:24:29 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Saturday, 10 March 2012 06:22:09 GMT