[
https://issues.apache.org/jira/browse/DAFFODIL-2017?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16757424#comment-16757424
]
Steve Lawrence commented on DAFFODIL-2017:
------------------------------------------
The TDML tests may just work as part of the type arware infoset comparisions.
We do type type aware comparisions if *either* the expect infoset or the actual
infoset contain the xsi:type attribute. IBM provides the attribute on the
infoset output, so this tests should still be type aware regardless of the
expected infoset in the TDML. Though, the tests may need to be updated to add
"ibm" to the implementation attribute, and we should validate these tests do in
fact pass with IBM Though, it would't hurt to add the xsi:type information to
the expected inoset as well. That way if some day we test against another
implementation it can do type aware comparisions regardless if they output the
xsi:type information.
I'm still in favor of an compatbility tunable though (maybe compatabilty="ibm",
allowing for compatability with other implementations, or even specific
versions of ibm). It's very possible some users of IBM DFDL are too specific
about extracting date/time information from infosets in way that isn't
compatable with what Daffodil outputs. One could argue that's a bug in their
system, but anything to make using Daffodil easier for people already
experienced with DFDL is a good thing.
So, yes the test should probably be updated, but I still think a compat flag
has value.
> Non-portable date/time test_simple_type_properties_text_calendar_13_02
> ----------------------------------------------------------------------
>
> Key: DAFFODIL-2017
> URL: https://issues.apache.org/jira/browse/DAFFODIL-2017
> Project: Daffodil
> Issue Type: Bug
> Components: Back End, Compatibility
> Affects Versions: 2.2.0
> Reporter: Michael Beckerle
> Assignee: Josh Adams
> Priority: Major
> Labels: ForInteroperabilityTest
>
> Ran under IBM DFDL. The test failed.
> Differences are
> * IBM uses "Z" where Daffodil uses "+00:00"
> * IBM shows "000" for fractional seconds where Daffodil does not
> Question is: which one is correct and why. If "both" behaviors are "allowed",
> then we likely need a switch in Daffodil to prefer the same behavior as IBM
> DFDL, vs. staying with the current behavior (which we still need to preserve
> for existing users.)
> Here's the output when running on IBM DFDL.
> {{org.apache.daffodil.tdml.TDMLExceptionImpl: (Implementation: ibm)
> Comparison failed.
> Expected
>
> <calendar_group><date1>2010-12-30+00:00</date1><time1>04:05:06+01:00</time1><datetime1>2010-12-30T04:05:06+00:00</datetime1></calendar_group>
> Actual
>
> <calendar_group><date1>2010-12-30Z</date1><time1>04:05:06.000+01:00</time1><datetime1>2010-12-30T04:05:06.000Z</datetime1></calendar_group>
> Differences were (path, expected, actual):
> (calendar_group/date1,'2010-12-30+00:00','2010-12-30Z')
> (calendar_group/time1,'04:05:06+01:00','04:05:06.000+01:00')
> (calendar_group/datetime1,'2010-12-30T04:05:06+00:00','2010-12-30T04:05:06.000Z')}}
> The same issues arise for these tests:
> test_simple_type_properties_text_calendar_13_03
> test_simple_type_properties_text_calendar_13_04
> test_simple_type_properties_bin_calendar_13_01
> test_simple_type_properties_bin_calendar_13_02
> test_length_delimited_12_01
> test_length_delimited_12_02
>
> These tests originated with IBM (a LONG time ago), though it's possible we
> changed them to match Daffodil behavior if we thought the behavior was
> correct the way we changed it.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
