[jira] [Assigned] (DAFFODIL-3077) XMLUtils comparison relies on specific ICU versions

["Guichard Desrosiers (Jira)" <ji...@apache.org>]

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

Guichard Desrosiers reassigned DAFFODIL-3077:
---------------------------------------------

    Assignee: Guichard Desrosiers

> XMLUtils comparison relies on specific ICU versions
> ---------------------------------------------------
>
>                 Key: DAFFODIL-3077
>                 URL: https://issues.apache.org/jira/browse/DAFFODIL-3077
>             Project: Daffodil
>          Issue Type: Bug
>          Components: TDML Runner
>    Affects Versions: 4.1.0
>            Reporter: Steve Lawrence
>            Assignee: Guichard Desrosiers
>            Priority: Major
>
> The XMLUtils compareAndReport calls the textIsSame function to do type-aware comparison when xsi:type is defined. However, if xsi:type is xs:date/time/dateTime, then we use the DFDLDate/Time/DateTimeConversion.fromXMLString function to convert the infoset string to an object for equality comparison.
> However, these date/time converters create and use ICU objects. This can cause issues when trying to test with the IBM DFDL cross tester, which depend on an older version of ICU. For example, the conversters can call "Calendar.clone()", which is only available in newer ICU versions.
> Some potential options:
> # Rewrite the calendar conversion classes to only use functions that are compatible with older versions of ICU. IBM DFDL uses ICU 51.1, so we should at least support that so we can continue cross testing
> # Rewrite TDML date/time comparison using the java.time package. The supported patterns are fairly limited and do not require ICU complexities
> # Simplfy date/time type comparisons with custom logic. I believe the only differences we have ever seen with date times is in extra sub-second decimal point precision (e.g. 1.234000 vs 1.234). It's possible there could be other differences (e.g. timezones), but one could argue that timezone information is important and so should not be canonicalized in the infoset and that two date/times with different timezones should never be considered the same. We could add custom parsing logic to the TDML Runner to ignore these trailing sub-second zeros as long as we confirm the trailing zeros are part of the sub-seconds part of a time/dateTime.
> Note that this is potentially more important once DAFFODIL-182 is fixed, which enables xsi:type and thus could allow for more type-aware comparisons.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)