I'm ok adding this now, so long as there are comments in the code easily found indicating this is non-portable DFDL feature. E.g., put keyword "PORTABILITY" in the comments so that we can search it easily.
The idea is in the future, should portability become a bigger deal than now, we can add some sort of portability check and warnings/errors easily. On Wed, Sep 25, 2024 at 3:29 PM Kilo, Olabusayo <ok...@owlcyberdefense.com> wrote: > > I currently have some code that adds support for date/time/datetime types and > binary packed decimal representations (DAFFODIL-2931), as per what the spec > currently says: > > > 'bits' may only be used for xs:boolean, xs:byte, xs:short, xs:int, xs:long, > > xs:unsignedByte, xs:unsignedShort, xs:unsignedInt, and xs:unsignedLong > > simple types with binary representation, and for calendar (date and time) > > simple types with binary packed representation. > > Do we want to wait for a spec update to remove the warning, or should I > update the code to drop the warning and add support for all types now and > push my changes? > > -- > Lola Kilo > ________________________________ > From: Mike Beckerle <mbecke...@apache.org> > Sent: Saturday, September 21, 2024 1:27 PM > To: dev@daffodil.apache.org <dev@daffodil.apache.org> > Subject: Re: Questions about addressing warnings for daf-2926 > > On Thu, Sep 19, 2024 at 3:20 PM Kilo, Olabusayo > <ok...@owlcyberdefense.com> wrote: > > > > Below are some warnings that need some discussion on how best to approach > > > > (noEmptyDefault) Element with no empty representation. Xsd default can only > > be used when unparsed > > > > * > > this warning shows up when an element cannot be empty (ex has > > dfdl:length=1), but has a default value. As discussed with Steve, default > > is ignored when parsing, and can only be applied on unparsing. We also > > discussed updating the warning to say "Element with no empty > > representation. XSD default='xxx' will be ignored when parsing." > > (DAFFODIL-2929). > > * > > The question is how to handle the tests that display this warning. Some > > suggestions are to: > > * > > add the warning to all the affected tests > > * > > suppress this warning in the schema > > * > > Affected Tests > > * > > org.apache.daffodil.section00.general.TestUnparserFileBuffering#test_parseFixedLengthStringLength0_ffb > > * > > org.apache.daffodil.section00.general.TestUnparserGeneral#test_parseFixedLengthStringLength0 > > * > > org.apache.daffodil.section13.boolean.TestBoolean#test_booleanDefault > > I think for the above, the "suppress this warning in the schema" is > the right thing. > > > > > > > (deprecatedBigIntegerBits)In a future release, lengthUnits='bits' will only > > be supported for the following types: xs:boolean, xs:byte, xs:int, xs:long, > > xs:short, xs:unsignedByte, xs:unsignedInt, xs:unsignedLong, xs:unsignedShort > > > > * > > this warning shows up when we use lengthUnits='bits' for xs:date or > > xs:dateTime. On discussing with Steve, he thinks this may be a bug due to > > the fact that we support bits on hexBinary and should support bits on > > xs:date for example for the IBM4690Packed binaryCalendarRep which needs a > > length that is a multiple of 4, which means we can't use bytes. Thoughts? > > Yes this is a bug. Bits should be allowed without warning for the > date/time/datetime types and binary packed decimal representations. > > In fact we should just drop this warning entirely, as DFDL Workgroup > issue https://github.com/OpenGridForum/DFDL/issues/12 is about opening > up use of lengthUnits 'bits' to all types. (Originally it was about > hexBinary, but integer, nonNegativeInteger, float, double, and even > string should be able to use lengthUnits 'bits' also. > > > * > > Affected Tests > > * > > org.apache.daffodil.section05.simple_types.TestSimpleTypes#test_dateBinIBM4690Packed2 > > * > > org.apache.daffodil.section05.simple_types.TestSimpleTypes#test_dateBinBCD5 > > * > > org.apache.daffodil.section12.lengthKind.TestLengthKindPrefixed#test_pl_bin_date_bin_bits_bcd > > * > > org.apache.daffodil.section12.lengthKind.TestLengthKindPrefixed#test_pl_bin_dec_bin_bits > > * > > org.apache.daffodil.section12.lengthKind.TestLengthKindPrefixed#test_pl_bin_hex_bin_bits > > * > > org.apache.daffodil.section12.lengthKind.TestLengthKindPrefixed#test_pl_bin_dec_bin_bits_bcd > > * > > org.apache.daffodil.section12.lengthKind.TestLengthKindPrefixed#test_pl_bin_dec_txt_bits > > * > > org.apache.daffodil.section12.lengthKind.TestLengthKindPrefixed#test_pl_bin_date_bin_bits_ibm4690 > > * > > org.apache.daffodil.section12.lengthKind.TestLengthKindPrefixed#test_pl_bin_dec_bin_bits_ibm4690 > > * > > org.apache.daffodil.section12.lengthKind.TestLengthKindPrefixed#test_pl_bin_hex_txt_bits > > * > > org.apache.daffodil.section12.lengthKind.TestLengthKindPrefixed#test_pl_bin_dec_bin_bits_packed > > * > > org.apache.daffodil.section12.lengthKind.TestLengthKindPrefixed#test_pl_bin_date_bin_bits_packed > > > > > > > > -- > > Lola Kilo
