W3C home > Mailing lists > Public > public-qt-comments@w3.org > September 2010

[Bug 10729] 4.5.1 fn:format-integer - usability issue with third argument

From: <bugzilla@jessica.w3.org>
Date: Sat, 25 Sep 2010 08:27:30 +0000
To: public-qt-comments@w3.org
Message-Id: <E1OzQ6U-0006kF-I0@jessica.w3.org>

--- Comment #1 from Michael Kay <mike@saxonica.com>  2010-09-25 08:27:29 ---
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...."

Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
Received on Saturday, 25 September 2010 08:27:34 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:57:32 UTC