[ 
https://issues.apache.org/jira/browse/DAFFODIL-1443?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Michael Beckerle updated DAFFODIL-1443:
---------------------------------------
    Priority: Minor  (was: Blocker)

> escapeCharacter expression evaluated when lengthKind 'delimited' on complex 
> element when there are no delimiters
> ----------------------------------------------------------------------------------------------------------------
>
>                 Key: DAFFODIL-1443
>                 URL: https://issues.apache.org/jira/browse/DAFFODIL-1443
>             Project: Daffodil
>          Issue Type: Bug
>          Components: Compatibility, Front End, Performance
>    Affects Versions: 1.1.0
>            Reporter: Michael Beckerle
>            Priority: Minor
>              Labels: ForInteroperabilityTest
>             Fix For: 2.4.0
>
>
> I'm trying to get EDIFACT working on Daffodil.
> This schema uses dfdl:escapeCharacter and dfdl:escapeEscapeCharacter as 
> expressions. E.g., there is a top-level dfdl:defineVariable named 
> "EscapeChar" which has a default value, and the expression for the 
> dfdl:escapeCharacter property is { $ibmEdiFmt:EscapeChar }.
> The default format that is in effect for the root element 'Interchange' has 
> dfdl:lengthKind='delimited'.
> When daffodil starts parsing the top level root/document element, it enters a 
> parser that is for delimited elements with an escape-scheme in effect. First 
> thing this parser does is get the escape scheme which evaluates the 
> expressions for escapeCharacter and escapeEscapeCharacter. This picks up the 
> default values for those variables and the variables are then set as "already 
> evaluated", as DFDL specifies that once a variable's default value has been 
> used, it cannot be subsequently set via dfdl:setVariable.
> Now, when the very first UNA is encountered, that reads the various 
> delimiters/escapes from the data, and tries to set the variables.
> But the variables have already been evaluated, on the way into parsing the 
> "delimited" top level element.
> So it fails with a runtime SDE - default value has already been used for 
> EscapeChar variable.
> So this clearly a bug. 
> The principle is that a complex-typed element of length kind delimited when 
> there is no definition of terminator nor applicable separator, that this 
> situation is treated like dfdl:lengthKind='implicit' and the escapeScheme is 
> therefore not relevant and the expressions for the escapeScheme characters 
> MUST NOT be evaluated.
> One could argue that the EDIFACT schema should have 
> dfdl:lengthKind='implicit' on the 'Interchange' element and any other complex 
> type element, but this is quite burdensome on the schema author, who 
> after-all thinks of this entire format as "delimited stuff".



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Reply via email to