This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
The text needs some further changes to handle the introduction of casting to list and union types. 17.1, Constructor functions for built-in types, only mentions atomic types; it should also cover the built-in list types. Where it mentions new XSD 1.1 types, it should also name them (there is only one: precisionDecimal has gone away). The question of the return type of a constructor function for list and atomic types requires some careful analysis. For a list type whose item type is atomic, the result type is A* where A is the atomic item type (we can't be more precise and say A+ if the list has a minOccurs facet of 1 or more, which applies to the built-in list types, because the function will always return () if the input is ()). For a union type that is a "restricted union type" (which in bug 17181 I propose renaming as a "constructed union type") the result type of the constructor function is that union type. For a union type that is derived by restriction from a "restricted union type", by one or more restriction steps, the result type is the "restricted union type" from which the target type is derived. For any other union type (which I think means a union type whose transitive membership includes union types that are not "restricted union types", or whose transitive membership includes list types), the result type is xs:anyAtomicType if there are no list types in the transitive membership, or xs:anyAtomicType* if there are. (But do we want to spell all this out? We could just say that the return type is xs:anyAtomicType*, and leave the implementation to do better if it chooses. I don't think there are any adverse consequences of specifying an over-loose return type except on implementations that do static typing - which are surely a dying breed?) For a list type whose item type is a union type, similar reasoning applies... Section 17.2 on constructors for QName and Notation should say something about how the context is handled when such functions are used as named function references, or located dynamically using function-lookup (or the useless but permitted case of partial function application). We now allow context-sensitive functions in such cases, and should mention this. Section 17.3 contains the spurious example function name fn:my:hatSize.
The WG meeting on 2012-06-12 agreed with the general direction here, subject to approval of detailed text. The WG decided not to attempt to specify a detailed return type for constructor functions for union and list types, specifying it instead as xs:anyAtomicType*. The following changes have been applied, subject to final approval. 17.1 Mention xs:dateTimeStamp explicitly rather than referring vaguely to new XSD 1.1 types. New section 17.2 defining constructor functions for xs:NMTOKENS, xs:IDREFS, and xs:ENTITIES. The return type of these is given as xs:NMTOKEN*, xs:IDREF*, and xs:ENTITY* respectively. The argument type is xs:string? (the function returns an empty sequence only if the input is an empty sequence; conversion of a zero-length string fails because these types all specify minLength="1". For user-defined simple types of variety list and union, the argument type is xs:string? and the return type is xs:anyAtomicType*. In the section on QName and Notation, a paragraph has been added explaining the impact on function literals, partial function application, and function-lookup. A revised draft containing these changes will be posted.
The WG examined the posted draft containing these changes and accepted them with two corrections (which sadly are not recorded in the minutes, so this relies on my own notes). In the signatures for built-in list constructors, given in the form: fn:NMTOKENS($arg as xs:string?) as xs:NMTOKEN? (a) the return type should be xs:NMTOKEN* [this was actually a stylesheet bug in formatting the spec] (b) the argument type should be xs:anyAtomicType?, for consistency with other constructors. The implication is that if the supplied argument is of a type that cannot be converted, the error is a dynamic error FORG0001 rather than a type error XPTY0004. These changes have been made, so the bug is being marked resolved/closed.