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

Hi Roland,

Good to hear you're still keeping us on track :-)

It's true that it may not be simple starting from scratch, but I believe 
that the XPath 2.0 team have already done the heavy lifting for us in this 
case.  Even though we are not adopting XPath 2.0 quite yet, it is 
reasonable to refer to XPath 2.0 for the definition of a compare() 
function for use in XForms 1.1.

XPath 2.0's compare(xs:string, xs:string) returns -1, 0, or 1 based on 
codepoint comparison.  Another variant of the function provides a third 
parameter for a URI that acts as an algorithm identifier for a collation 
method.  In other words, the simple two-parameter compare is the same as 
the three parameter version except it defaults the third parameter to the 
codepoint method using 
http://www.w3.org/2005/xpath-functions/collation/codepoint.  Note that 
although any collation algorithm is theoretically possible, the fact is 
that only the codepoint algorithm is required to implement.

Since the spec work is almost entirely done for us and since only the 
codepoint method is required and the others are optional (XPath 2.0 does 
not even fall into the trap of *trying* to define them), I believe we can 
end up with the same benefit of being able to compare strings without 
getting bogged down in unnecessary details.

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





Roland Merrick <roland_merrick@uk.ibm.com> 
03/10/2007 01:24 AM

To
John Boyer/CanWest/IBM@IBMCA
cc
www-forms@w3.org, www-forms-editor@w3.org, www-forms-editor-request@w3.org
Subject
Re: Last call comment: XForms 1.1 is missing a string compare capability







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