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

Peter, providing a vendor-defined function in your own namespace is in no
way a departure from the specification.
 
If you want the function to be interoperable you could consider submitting
it to the EXSLT library. (www.exslt.org). Although this has only been used
for XSLT functions in the past I see no reason why the same functions should
not be defined for use in XQuery. The nice thing about EXSLT is that if two
vendors want to implement the same function, they can do it with the same
name and the same specification, without any implication that all other
vendors have to provide it too; you can also supply a "user-written"
implementation that people can include in their code when using a product
that doesn't support the function natively.
 
Michael Kay


  _____  

From: public-qt-comments-request@w3.org
[mailto:public-qt-comments-request@w3.org] On Behalf Of Peter Coppens
Sent: 16 November 2004 22:52
To: 'Ashok Malhotra'; public-qt-comments@w3.org
Subject: RE: Request for yet another function - truncating trailing spaces
for string values


Ashok,
 
I'd like to thank the joint WG to consider this late comment and you for
providing the feed-back. 
 
Given the specific 'implementation trench' the comment originated from, I do
like to point out that until now, I have not found an XQuery compliant
solution that would also translate efficiently to commonly supported SQL
dialects (which of course might well be due to my lack of knowledge of the
these SQL dialects).
 
Anyway, given the fact that no majority within the joint WG could be found
to support this proposal, it seems I will have to shift my efforts from
influencing the spec to finding support to divert from the spec in this
specific situation. 
 
Thanks,
 
Peter
 
 
  _____  

From: Ashok Malhotra [mailto:ashok.malhotra@oracle.com] 
Sent: Tuesday, November 16, 2004 12:48 PM
To: pgp.coppens@pandora.be; public-qt-comments@w3.org
Subject: RE: Request for yet another function - truncating trailing spaces
for string values


Peter:
Thank you for your note.
 
The joint WGs discussed your request on November 9 and decided against
adding
such a function on the grounds that it was not difficult for users to write
such a function.
In fact, if someone would provide the definition of a function to trim
trailing spaces
from a string we could add it to Appendix D -- Illustrative User-written
functions.
 
Please let us know if this resolution is satisfactory.

All the best, Ashok 

 


  _____  

From: public-qt-comments-request@w3.org
[mailto:public-qt-comments-request@w3.org] On Behalf Of Peter Coppens
Sent: Thursday, September 16, 2004 1:39 PM
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