RE: Request for yet another function - truncating trailing spaces for string values

Thanks Michael,
 
One question though - normalize-space crossed our mind as well, but what
about 'consecutive spaces in the middle of the string'. Would all of those
except one not be 'eaten' by normalize-space?
 
Thanks,
 
Peter


  _____  

From: Michael Kay [mailto:mhk@mhk.me.uk] 
Sent: Thursday, September 16, 2004 11:28 PM
To: pgp.coppens@pandora.be; public-qt-comments@w3.org
Subject: RE: Request for yet another function - truncating trailing spaces
for string values


An observation: I imagine that in many cases if trailing spaces are not
significant then leading spaces (and multiple internal spaces) won't be
significant either, so normalize-space() will do the job.
 
Michael Kay


  _____  

From: public-qt-comments-request@w3.org
[mailto:public-qt-comments-request@w3.org] On Behalf Of Peter Coppens
Sent: 16 September 2004 21:39
To: public-qt-comments@w3.org
Subject: Request for yet another function - truncating trailing spaces for
string values


Gentlepeople,
 
I fully understand that the period for 'functional' comments on the spec is
closed, but as this is information from the 'implementation trenches', just
perhaps a few cycles of some working group member can be diverted for a
moment.
 
I think that for a subset of environments (e.g. those that use XQuery to
query existing relational information) it would be beneficial to have a
function that removes trailing spaces from a string value (as in SQL's rtrim
function).
 
The reason is that fixed character RDBMS columns end up being mapped (per
the SQL 2003 spec) with trailing spaces where needed. That's nice, as it
fully exposes the available RDBMS information, but often these trailing
spaces have no real meaning for the application.
 
The only solution we could find to remove these trailing spaces based on the
currently available F&O's is through something like fn:replace ( 'abc ', '
*$', ''). The need to fall back on regular expressions (often not available
in the different SQL implementations) seems overkill for such a simple an
most likely often needed operation. 
 
Of course we are free to define our own non-standard function and of course
people should not put varying length data in fixed length character columns,
but the case in favour for such a function nevertheless seems strong enough
for me to bother you with this.
 
Thanks,
 
Peter