Bug #2043
closed
Empty maps not passing type checking inside compound <xsl:map> statements
Category:
XSLT conformance
Fixed in Maintenance Release:
Description
The attached stylesheet reports an error:
XTTE0570: Required item type of value of variable $daily.fact.map is (map(xs:date, (map(xs:string, xs:string*)); supplied value has item type (map(xs:date, map(*))
This error appears to be due to $putative.map being an empty map when the instruction is executed on the 2nd iteration of the xsl:iterate instruction. This means that xsl:map-entry is mapping an xs:date to an empty map. But this should be legal because an empty map satisfies the requirement of map(xs:string,xs:string*), otherwise, the xsl:param statement in the xsl:itereate instruction would throw an error.
Files
- Category set to XSLT conformance
- Assignee set to Michael Kay
- Priority changed from Low to Normal
Thanks for reporting it. I've reproduced it and understand the cause; fixing it is a bit more tricky.
Progress report:
What's happening is that the check on whether a map conforms to a given map type is using information held within the map about the types of the keys and the values, and returns true if and only if this stored type is a subtype of the required type. But the stored type information is not as precise as it needs to be, because it uses a "least common subtype" algorithm that approximates unions. So if the stored type isn't a subtype, then it's necessary to inspect each of the key-value pairs (which is not currently happening). Fixing this is complicated by the fact that iterating over the key-value pairs, in the case of a map whose keys are dates, requires access to the dynamic context (matching of dates depends on the implicit timezone), and no dynamic context is available at this point in the code.
It's possible to fix this particular incident by recognizing the empty map as a special case, and I may do this for 9.5, leaving a more general solution to 9.6.
Question: Is this problem specific to maps whose type involves xs:date (or xs:dateTime)? If $daily.fact.map were of type map(xs:string, map(xs:string, xs:string*)), would it still be an issue?
The problem isn't specific to dates, but the solution is complicated by the fact that the map is context-sensitive. That's just an accident of the way the code is written. I'm working on a 9.6 solution at the moment, and introducing the ability to iterate over all the entries in the map (a context-free operation) rather than iterating over the keys and then getting the value corresponding to each key (which is context-sensitive, since date matching depends on implicit timezone).
- Status changed from New to Resolved
- Found in version changed from 9.5.1.3 EE to 9.5
It's not actually direcly connected with empty maps; compound maps are more to the nub. What's happening is that we have a map with two entries, and each the value-part of the entry is a map. Each of these two maps has an inferred type, but the logic for finding the lowest common supertype of these two maps is flawed. Rather than attempt to fix this logic, I have introduced code so that if the "crude" type of a map doesnt' match the expected type, we then iterate over the entries in the map testing each entry to check whether the key and the value both conform to the parameters of the required map type. The fix for this is complicated by the need to introduce a context-free way of iterating over the entries in a map; the existing mechanism (iterating over the keys, and for each key, getting the assoicated value) is context-dependent because the implicit timezone is needed for comparing date/time keys.
A solution has been applied on both the 9.5 and 9.6 branches; the 9.6 version is a bit smarter.
- Status changed from Resolved to Closed
- % Done changed from 0 to 100
- Fixed in version set to 9.5.1.6
Bug fix applied in Saxon maintenance release 9.5.1.6
Please register to edit this issue
Also available in: Atom
PDF
.