Bug #6092
closedXSD: defaultOpenContent/@appliesToEmpty not working?
100%
Description
To implement the rules for the proposed xsl:note element in the schema for XSLT 4.0, I am using a defaultOpenContent
declaration with appliesToEmpty=true
. This doesn't appear to be working: test case note-007, which has an
xsl:noteelement as a child of
xsl:strip-space`, is rejected as invalid.
Summary
defaultOpenContent
with appliesToEmpty=true
is not working in the case of a complex type with a locally empty content model that is derived by extension from another complex type with a locally empty content model; the resulting type is classified (and validated) as empty without taking the openContent into account.
Updated by Michael Kay 10 months ago
I checked that there are tests in this area, e.g. open-040 et seq in the Saxon test contributions; so it's not something that's completely untested or unimplemented, although it's certainly not widely used.
Updated by Michael Kay 10 months ago
I think that the problem is around UserComplexType line 1947 where it does
if (contentModel.isEmpty()) {
extendedParticle = null;
if (variety == ComplexVariety.ELEMENT_ONLY) {
variety = ComplexVariety.EMPTY;
}
}
to set the content model to empty when it finds that a complex type derived by extension and its base type both have empty content models. I suspect it shouldn't be doing this if there is an open content wildcard that applies to empty elements.
Updated by Michael Kay 10 months ago
Indeed, this appears to fix the problem. Change if (contentModel.isEmpty())
in this code to
if (contentModel.isEmpty() && (openContentWildcard == null || !openContentAppliesToEmpty))
so that the content model remains ELEMENT_ONLY rather than EMPTY if there is an open content wildcard.
Updated by Michael Kay 10 months ago
- Status changed from New to Resolved
- Applies to branch 11, 12, trunk added
- Fix Committed on Branch 11, 12, trunk added
Updated by O'Neil Delpratt 10 months ago
- Status changed from Resolved to Closed
- % Done changed from 0 to 100
- Fixed in Maintenance Release 12.3 added
Bug fix applied in the Saxon 12.3 maintenance release.
Updated by O'Neil Delpratt 10 months ago
- Status changed from Closed to Resolved
Leaving this bug issue as resolved until resolved against Saxon 11.
Updated by Debbie Lockett 8 months ago
- Status changed from Resolved to Closed
- Fixed in Maintenance Release 11.6 added
Bug fix applied in the Saxon 11.6 maintenance release.
Please register to edit this issue