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 over 1 year 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 over 1 year 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 over 1 year 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 over 1 year 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 over 1 year 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 over 1 year ago
- Status changed from Closed to Resolved
Leaving this bug issue as resolved until resolved against Saxon 11.
Updated by Debbie Lockett over 1 year 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