This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 10729 - 4.5.1 fn:format-integer - usability issue with third argument
Summary: 4.5.1 fn:format-integer - usability issue with third argument
Status: CLOSED FIXED
Alias: None
Product: XPath / XQuery / XSLT
Classification: Unclassified
Component: Functions and Operators 3.0 (show other bugs)
Version: Working drafts
Hardware: PC Linux
: P2 normal
Target Milestone: ---
Assignee: Michael Kay
QA Contact: Mailing list for public feedback on specs from XSL and XML Query WGs
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2010-09-24 17:09 UTC by O'Neil Delpratt
Modified: 2010-09-28 16:16 UTC (History)
0 users

See Also:


Attachments

Description O'Neil Delpratt 2010-09-24 17:09:45 UTC
Hi,

I would like to raise a usability issue relating the format-integer function.The optional third argument (i.e. $language as xs:language) is somewhat error prone from a users prospective, it would be simpler maybe to have the type as xs:string.

For example: 

<xsl:for-each select="number">
  <out>
    <xsl:value-of select="format-integer(. ,'w','de' cast as xs:language)"/>  
  </out>
</xsl:for-each>

We observe the user is forced into casting the 'de' as xs:language, rather than the more natural approach:

<xsl:value-of select="format-integer(. ,'w','de')"/>
Comment 1 Michael Kay 2010-09-25 08:27:29 UTC
Indeed, we generally define functions to expect primitive types for this reason: examples are fn:lang() which expects a language code in the form of a string, fn:remove() which expects a positive integer in the form of an xs:integer; there are also many functions that logically expect a URI, where we allow a string to be passed for user convenience.

Since we've developed the habit of relaxing function signatures for user convenience in this way, I wonder if this indicates a problem with the language design? Perhaps rather than treating each case individually, we should change the function conversion rules to allow implicit downcasting? That is, if a function signature declares an argument of type xs:language or xs:positiveInteger, we should allow a value of the corresponding primitive type to be supplied, and cast it implicitly. For user-defined functions, this would mean that authors of functions could get implicit validation of a function parameter such as an xs:NCName without the adverse consequence of requiring the caller to do an explicit cast.

Editorial note: in looking again at the spec for format-integer, it seems to me that the repeated use of the phrase "generates a sequence" is potentially confusing. This derives from its use in xsl:number, where it's a bit more defensible. I propose to change "A format token A generates the sequence A B C ... Z AA AB AC...." to "A format token A produces a value from the sequence A B C ... Z AA AB AC...."
Comment 2 Michael Kay 2010-09-28 16:07:56 UTC
The WG agreed to change the signature to require a string, with a dynamic error if the string is not castable to xs:language, leaving the wider issue open for future discussion.

O'Neil, please close the bug if you are happy with this resolution.