Bug #5782
closed
ClassCastException casting SimpleTypeDefinition to AtomicType
0%
Description
When calling "fn:data( $input as item()*) as xs:anyAtomicType* external;"
with simpleType
<xsd:simpleType>
<xsd:restriction base="xs:string">
<xsd:whiteSpace value="collapse"/>
<xsd:length value="20"/>
</xsd:restriction>
</xsd:simpleType>
we are getting
java.lang.ClassCastException: class com.saxonica.ee.schema.sdoc.SimpleTypeDefinition cannot be cast to class net.sf.saxon.type.AtomicType (com.saxonica.ee.schema.sdoc.SimpleTypeDefinition and net.sf.saxon.type.AtomicType are in unnamed module of loader 'app')
Files
Updated by Michael Kay over 1 year ago
- Subject changed from ClassCastException to ClassCastException casting SimpleTypeDefinition to AtomicType
- Category changed from XPath conformance to Schema-Aware processing
- Status changed from New to AwaitingInfo
- Assignee set to Michael Kay
- Fix Committed on Branch 11 added
- Platforms Java added
Thanks for reporting this, but I don't think we'll be able to fix it without a full repro - in particular, the full schema, but ideally an XPath (or XQuery etc) that shows the failure reproducibly; we'll need that to ensure that any patch actually works.
I know what the general problem area is. When a simpleType is first encountered in a schema, it's not always possible to tell immediately whether it's an atomic, list, or union type. That's because we might not yet know anything about the base type. So we provisionally allocate a SimpleTypeDefinition object, to be resolved later. By the time we come to actually use a schema, there should be no SimpleTypeDefinition objects left, they should all have been replaced by an AtomicType, ListType, or UnionType. So something has gone wrong, but we don't know what.
It's a problem that used to crop up quite frequently but we haven't seen it for many years now.
Another observation: at the point of failure, it's parsing a type declaration in a "let" clause within a FLWOR expression. I'm having trouble reconciling that with your code fragment, which looks like an XQuery function declaration in an XQuery prolog; except that you wouldn't normally have an external function declaration for a built-in (internal) function like fn:data. I don't really understand what you are doing when the failure occurs.
Updated by Rene Schulze over 1 year ago
- File simple.xsd simple.xsd added
we are calling the built-in (internal) function fn:data(...) with the parameter "Example"in the attached simple.xsd
Updated by Michael Kay over 1 year ago
I haven't been able to reproduce the problem from the information given.
I ran the following query from the command line and it runs fine:
java net.sf.saxon.Query -qs:"import schema namespace s='http://example.net/datatypes/simple'
at 'file:///Users/mike/bugs/2023/5782-Schulze/simple.xsd';
let $d := validate type s:Example {<Example>01234567890123456789</Example>} return data($d)"
I need to know in more detail exactly what you were doing. In particular, the way you build the schema is probably relevant. Please give precise steps that we can follow to reproduce the error.
Updated by Michael Kay over 1 year ago
- Status changed from AwaitingInfo to Closed
- Priority changed from High to Normal
I would love to get to the bottom of this issue but we can't solve it without more information, so I'm closing it as unresolved.
If you are able to get us a repro, please re-open the issue.
Please register to edit this issue
.