The mapping has already been fixed in the main branch and will be part of the upcoming 3.7.0 release. This was fixed in DAFFODIL-2882. If you use the mapping below to update your schemas to use separatorSuppressionPolicy, your schemas should work on both 3.6.0 and 3.7.0.

  separatorPolicy         separatorSuppressionPolicy
   required                 never
   suppressed               anyEmpty
   suppressedAtEndStrict    trailingEmpty
   suppressedAtEndLax       trailingEmptyStrict

If you want to continue using separatorPolicy with Daffodil 3.7.0, you'll need to change uses of "suppressedAtEndStrict" to "suppressedAtEndLax", and vice versa, to keep your current behavior, since 3.7.0 fixes the internal mapping from separatorPolicy to separatorSuppresionPolicy.

- Steve

On 2024-03-20 08:55 AM, Claude Mamo wrote:
Should I create a JIRA issue for this?

Claude

On Wed, Mar 13, 2024 at 3:24 PM Steve Lawrence <slawre...@apache.org <mailto:slawre...@apache.org>> wrote:

    Yep, we do still have some tests that use separatorPolicy, but they only use
    "suppressed" or "required" values so we never caught that the other two were
    flipped. The EDIFACT schema does use "suppressedAtEndLax", but the couple of
    tests in the repo also work for "suppressedAtEndStrict", so we didn't notice
    the
    wrong behavior.

    On 2024-03-13 10:07 AM, Mike Beckerle wrote:
     > Wow. Having that mapping flipped seems pretty egregious. I guess we
     > updated all our schemas and so didn't have the tests of the older
     > property names.
     >
     > On Wed, Mar 13, 2024 at 7:29 AM Steve Lawrence <slawre...@apache.org
    <mailto:slawre...@apache.org>> wrote:
     >>
     >> Hmm, Daffodil has this internal mapping:
     >>
     >>     required -> never
     >>     suppressed  -> anyEmpty
     >>     suppressedAtEndStrict -> trailingEmpty
     >>     suppressedAtEndLax -> trailingEmptyStrict
     >>
     >>
    
https://github.com/apache/daffodil/blob/main/daffodil-lib/src/main/scala/org/apache/daffodil/lib/schema/annotation/props/ByHandMixins.scala#L198-L201
 
<https://github.com/apache/daffodil/blob/main/daffodil-lib/src/main/scala/org/apache/daffodil/lib/schema/annotation/props/ByHandMixins.scala#L198-L201>
     >>
     >> Note that suppressedAtEndStrict and suppressedAtEndLax are swapped
    compared to
     >> the errata document. Seems like this is a bug in Daffodil, but if you
    use the
     >> above mapping to update your schemas it *should* give you the same
    behavior as
     >> before.
     >>
     >>
     >> On 2024-03-13 04:53 AM, Claude Mamo wrote:
     >>> Hi Daffodil community,
     >>>
     >>> Quick question, I noticed a couple of Daffodils warnings during testing
    saying
     >>> that /separatorPolicy/ is deprecated and that I should use instead
     >>> /separatorSuppressionPolicy/. I followed this doc for migrating to the 
new
     >>> attribute: https://ogf.org/documents/GFD.214.pdf
    <https://ogf.org/documents/GFD.214.pdf>
     >>> <https://ogf.org/documents/GFD.214.pdf
    <https://ogf.org/documents/GFD.214.pdf>> :
     >>>
     >>>      3.14. Section 14.2. To better describe the property and its
    behaviour, property
     >>>      separatorPolicy is renamed to separatorSuppressionPolicy, and its
    enums
     >>>      renamed as
     >>>      follows:
     >>>
     >>>      ‘required’ -> 'never'
     >>>      ‘suppressed’ -> 'anyEmpty'
     >>>      ‘suppressedAtEndLax’ -> 'trailingEmpty'
     >>>      ‘suppressedAtEndStrict -> 'trailingEmptyStrict'.
     >>>
     >>>      Additionally the property description for
    separatorSuppressionPolicy is
     >>>      rewritten, introductory
     >>>      paragraphs are added to section 14.2, and section 14.2.1 is
    replaced with
     >>>      new tables.
     >>>      This is covered in DFDL experience document 2 [DFDLX2]
     >>>
     >>>
     >>> My understanding is that this is purely a cosmetic change but, after
    migrating
     >>> to the new attribute, the tests started to fail. Has the behaviour
    changed as
     >>> well? I'm on version 3.6
     >>>
     >>> Claude
     >>


Reply via email to