This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
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')"/>
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...."
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.