daffodil-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mike Beckerle (Jira)" <j...@apache.org>
Subject [jira] [Created] (DAFFODIL-2343) Misleading schema file location - right element, right first file, wrong second file
Date Wed, 20 May 2020 23:13:00 GMT
Mike Beckerle created DAFFODIL-2343:
---------------------------------------

             Summary: Misleading schema file location - right element, right first file, wrong
second file
                 Key: DAFFODIL-2343
                 URL: https://issues.apache.org/jira/browse/DAFFODIL-2343
             Project: Daffodil
          Issue Type: Bug
          Components: Diagnostics, Middle &quot;End&quot;
    Affects Versions: 2.6.0
            Reporter: Mike Beckerle
             Fix For: 3.0.0


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.

{code}
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
{code}
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:
{code}
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
{code}
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.





--
This message was sent by Atlassian Jira
(v8.3.4#803005)

Mime
View raw message