This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
A user of maps in XSLT 3.0 (David Rudel) asks whether we couldn't apply function conversion rules to the map content. For example <xsl:variable name="x" as="map(xs:string, xs:string)" select="map{@name : @value}"/> (Note: XSLT, unlike XQuery, uses the function conversion rules for variables as well as functions.) This currently gives a type error: although @name is atomized to a string, because the required type is atomic, the attribute @value is not atomized. It seems consistent with other parts of the language to do this, and it doesn't seem excessively difficult (convert the map to a new map by recursively applying the function conversion rules to all the keys and values). There are a few edge cases, such as conversion of the key values leading to duplicates. The main reason this wasn't done in XSLT 3.0 was to minimize changes to the XPath spec. Either that, or it was overlooked.
Michael Kay was actioned to produce a proposal to develop this idea.
The obvious first cut proposal would be as follows: add to the function conversion rules the bullet item: * If the expected type is a MapTest (possibly with an occurrence indicator *, +, or ?), map coercion is applied to each function in the given value. Map coercion is a transformation applied to maps during application of the function conversion rules. Given a map type with a required key type K and a required value type V, map coercion takes a supplied map and constructs a new map in which every key is converted to type K, and every value to type V, by recursive application of the function conversion rules. However, there are problems with this. The map produced by this process might have duplicate keys (for example, two different decimal values can be promoted to the same double value by the function conversion process). Furthermore, and for similar reasons, it's not easy to create the transformed map as a "virtual" map supporting efficient lookup operations (this is because the promotion rules are not readily reversible; if someone wants to look up the key 1e32 and the original map had decimal keys, you don't know what the original decimal key would have been. I think a workable solution to these difficulties is to coerce the values but not the keys. There is in fact little need to coerce the keys because they have already been atomized; the only further conversion that can occur is numeric promotion; and numeric promotion achieves little because we already define the equality relation across the numeric types ($M(2) will successfully retrieve an entry whose key is the double 2e0). So the revised proposal is: * If the expected type is a MapTest (possibly with an occurrence indicator *, +, or ?), map coercion is applied to each map in the given value. Map coercion is a transformation applied to maps during application of the function conversion rules. Given a map type with a required key type K and a required value type V, map coercion takes a supplied map and constructs a new map in which the keys are unchanged, but every associated value is converted to type V by recursive application of the function conversion rules.
The WG gave this detailed consideration and decided on balance not to make any change. One of the objections cited was that it would be easy to incur a potentially very expensive operation unintentionally; another was the absence of convincing use cases.