- From: <bugzilla@jessica.w3.org>
- Date: Sat, 25 Sep 2010 08:27:30 +0000
- To: public-qt-comments@w3.org
http://www.w3.org/Bugs/Public/show_bug.cgi?id=10729 --- 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