[
https://issues.apache.org/jira/browse/DAFFODIL-2888?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dave Thompson closed DAFFODIL-2888.
-----------------------------------
Verified the specified commit (commit 6b0e56e8c9af894a852779fea2fb4ba486b0963f)
is included in the latest pull from the daffodil repository.
Verified, via review, changes identified in the commit comment were
implemented.
Verified the affected daffodil subproject sbt test suites executed
successfully, including the modified and added tests.
> Incorrect out of range warning with constant dfdl:length and
> length/minLength/maxLength facets
> ----------------------------------------------------------------------------------------------
>
> Key: DAFFODIL-2888
> URL: https://issues.apache.org/jira/browse/DAFFODIL-2888
> Project: Daffodil
> Issue Type: Bug
> Components: Front End
> Reporter: Steve Lawrence
> Priority: Major
> Fix For: 3.9.0
>
>
> Say we have a schema like this:
> {code:xml}
> <element name="file" dfdl:lengthKind="explicit" dfdl:length="16"
> dfdl:lengthUnits="bits">
> <simpleType>
> <restriction base="xs:string">
> <maxLength value="2" />
> </restriction>
> </simpleType>
> </element>
> {code}
> So we have a 2-byte constant length string and we specify maxLength should be
> 2. However, because we specify the length in bits, the value of dfdl:length
> is greater than the value of maxLength and so we output a warning:
> {quote}
> [warn] Schema Definition Warning: Explicit dfdl:length of 16 is out of range
> for facet maxLength='2'. (id: facetExplicitLengthOutOfRange)
> {quote}
> The issue is this check does not take into account the units of length. It
> also does not take into account the character set of the data. For example,
> 1-byte of the X-DFDL-BITS-MSBF character set has a minLength of 8 characters
> in the infoset.
> There are other things to consider, for example, maybe we have a string with
> dfdl:length="3" with units of bytes, but we always expect to have 1 character
> of padding removed, so our maxLength wants to be 2. We would get a warning
> here too.
> Maybe some false positives are okay, but we can probably improve the logic to
> avoid false positives in some cases at least to take into account units and
> charsets? Or maybe this warning isn't really that helpful, and the compelxity
> needed to get it right is not worth it, and should be removed?
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
