Details
-
Bug
-
Status: Open
-
Minor
-
Resolution: Unresolved
-
2.6.0
-
None
-
None
Description
I suspect this is related to the sharing of group definitions in the schema compiler.
I have a group that is reused all over a very large schema (link16).
I am working on debugging a J3.2 message. But I am getting a diagnostic that mentions J9.1.
I suspect that it just so happens that this J9.1 schema file use of this group is the first one to be compiled, and so it was selected by the schema compiler to be the "cannonical" one for the purposes of sharing the definition. But then nothing should be using that object's schema-file-location, because it's going to be shared.
To make this clearer, here's the diagnostic messages. I'm going to break this up and talk about the parts that are right, and where it goes wrong.
org.apache.daffodil.tdml.TDMLExceptionImpl: (Implementation: daffodil) Parse Error: Choice dispatch branch failed: List(Parse Error: Failed to populate spare[1]. Cause: Parse Error: Insufficient bits in data. Needed 2 bit(s) but found only 0 available.
Schema context: spare Location line 79 column 8 in file:/home/mbeckerle/Documents/dataiti/git/dfdl-schemas/dfdl-link16/target/classes/com/tresys/mil-std-6016-common/xsd/mil-std-6016-common.dfdl.xsd
Data location was preceding byte 63 limit(bytes) 63
Everything above is perfect. The problem is with an element named 'spare' in a group defined in a file 'mil-std-6016-common.dfdl.xsd'.
Then things go bad:
Schema context: group[2] Location line 69 column 10 in file:/home/mbeckerle/Documents/dataiti/git/dfdl-schemas/dfdl-link16/target/classes/com/tresys/mil-std-6016f1/xsd/J9_1_engagement_coordination_link16.gen.dfdl.xsd
At that line 69 of that file, is a group reference to the group defined in mil-std-6016-common.dfdl.xsd.
The problem is, this isn't a relevant source file. My data doesn't contain any J9.1 information.
If you run the test with tracing turned on, the activity is all about the correct message which is J3.2. And I am certain that the problem is about a usage of this same shared group definition that is happening in the J3.2 message schema files.
The problem is just that the schema compiler is somehow associating J9.1 information about the file location for this group, as a side-effect of sharing definitions of groups for re-use.