clarification needed: prefixLengthType has min/max facets prefixIncludesPrefixLength="yes"
(Note: email sent to dfdl-wg at lists.ogf.org, not just ogf.org per prior practice.) Sometime back, in order to allow facets to sanity check prefix length values, we specified that if facets are expressed on a prefixLengthType they would always be checked and if they do not hold it is a processing error. This correction was part of the most recent GFD.240 However, we did not specify if the facet check is done on the prefix length value before or after it is adjusted when prefixIncludesPrefixLength="yes". So for example, suppose there is a single-byte prefix on a string and dfdl:prefixIncludesPrefixLength is "yes". Then the minimum well-formed value of the prefix is "1" which indicates a length 0 string with a single byte prefix. Suppose I want to add XSD facets to sanity check this prefix value: <simpleType name="prefix1Byte"> <restriction type="xs:unsignedByte"> <maxInclusive value="99"/> </restriction> </simpleType> So, if this type is used as the dfdl:prefixLengthType of a string with dfdl:lengthKind='prefixed', and dfdl:prefixIncludesPrefixLength="yes" then does the check for 99 measure the length of the string, or the value of the prefix, which is the length of the string plus one? My thought is that there is a quasi-element corresponding to this single byte prefix. That quasi-element's value is what is constrained by this maxInclusive facet. So I'm claiming the facet value 99 should be compared against the stored value in the prefix quasi-element, that is before any value adjustment is done for dfdl:prefixIncludesPrefixLength. Which is to say, suppose you switched to dfdl:lengthKind="explicit", and made an actual element of the single unsiged byte "prefix" field. Then the adjusting for the length of that prefix length would be done in the dfdl:length expression for the string, and the dfdl:outputValueCalc for the single byte prefix field. Which is to say that facets constraining the value of that one-byte element would apply to the value directly, not after any adjustment. I think lengthKind prefixed should work exactly the same as when a real length element and outputValueCalc are used. One should not have to adjust facets on the type of the length field when when it is the type of the length element, no should one have to adjust the facets if you convert and use lengthKind 'prefixed' with the dfdl:prefixLengthType, the facets should mean the same thing. Any thoughts/comments? Note: daffodil PR about this: https://github.com/apache/daffodil/pull/1334 JIRA Issue: https://issues.apache.org/jira/browse/DAFFODIL-2660
(Re-distributing as some people did not receive it.) Sometime back, in order to allow facets to sanity check prefix length values, we specified that if facets are expressed on a prefixLengthType they would always be checked and if they do not hold it is a processing error. This correction was part of the most recent GFD.240 However, we did not specify if the facet check is done on the prefix length value before or after it is adjusted when prefixIncludesPrefixLength="yes". So for example, suppose there is a single-byte prefix on a string and dfdl:prefixIncludesPrefixLength is "yes". Then the minimum well-formed value of the prefix is "1" which indicates a length 0 string with a single byte prefix. Suppose I want to add XSD facets to sanity check this prefix value: <simpleType name="prefix1Byte"> <restriction type="xs:unsignedByte"> <maxInclusive value="99"/> </restriction> </simpleType> So, if this type is used as the dfdl:prefixLengthType of a string with dfdl:lengthKind='prefixed', and dfdl:prefixIncludesPrefixLength="yes" then does the check for 99 measure the length of the string, or the value of the prefix, which is the length of the string plus one? My thought is that there is a quasi-element corresponding to this single byte prefix. That quasi-element's value is what is constrained by this maxInclusive facet. So I'm claiming the facet value 99 should be compared against the stored value in the prefix quasi-element, that is before any value adjustment is done for dfdl:prefixIncludesPrefixLength. Which is to say, suppose you switched to dfdl:lengthKind="explicit", and made an actual element of the single unsiged byte "prefix" field. Then the adjusting for the length of that prefix length would be done in the dfdl:length expression for the string, and the dfdl:outputValueCalc for the single byte prefix field. Which is to say that facets constraining the value of that one-byte element would apply to the value directly, not after any adjustment. I think lengthKind prefixed should work exactly the same as when a real length element and outputValueCalc are used. One should not have to adjust facets on the type of the length field when when it is the type of the length element, no should one have to adjust the facets if you convert and use lengthKind 'prefixed' with the dfdl:prefixLengthType, the facets should mean the same thing. Any thoughts/comments? Note: daffodil PR about this: https://github.com/apache/daffodil/pull/1334 JIRA Issue: https://issues.apache.org/jira/browse/DAFFODIL-2660
I agree with your conclusion (and with the PR :) Steve On Thu, Nov 14, 2024 at 5:33 PM Mike Beckerle <mbeckerle@apache.org> wrote:
(Re-distributing as some people did not receive it.)
Sometime back, in order to allow facets to sanity check prefix length values, we specified that if facets are expressed on a prefixLengthType they would always be checked and if they do not hold it is a processing error.
This correction was part of the most recent GFD.240
However, we did not specify if the facet check is done on the prefix length value before or after it is adjusted when prefixIncludesPrefixLength="yes".
So for example, suppose there is a single-byte prefix on a string and dfdl:prefixIncludesPrefixLength is "yes". Then the minimum well-formed value of the prefix is "1" which indicates a length 0 string with a single byte prefix.
Suppose I want to add XSD facets to sanity check this prefix value:
<simpleType name="prefix1Byte"> <restriction type="xs:unsignedByte"> <maxInclusive value="99"/> </restriction> </simpleType>
So, if this type is used as the dfdl:prefixLengthType of a string with dfdl:lengthKind='prefixed', and dfdl:prefixIncludesPrefixLength="yes" then does the check for 99 measure the length of the string, or the value of the prefix, which is the length of the string plus one?
My thought is that there is a quasi-element corresponding to this single byte prefix. That quasi-element's value is what is constrained by this maxInclusive facet. So I'm claiming the facet value 99 should be compared against the stored value in the prefix quasi-element, that is before any value adjustment is done for dfdl:prefixIncludesPrefixLength.
Which is to say, suppose you switched to dfdl:lengthKind="explicit", and made an actual element of the single unsiged byte "prefix" field. Then the adjusting for the length of that prefix length would be done in the dfdl:length expression for the string, and the dfdl:outputValueCalc for the single byte prefix field. Which is to say that facets constraining the value of that one-byte element would apply to the value directly, not after any adjustment. I think lengthKind prefixed should work exactly the same as when a real length element and outputValueCalc are used. One should not have to adjust facets on the type of the length field when when it is the type of the length element, no should one have to adjust the facets if you convert and use lengthKind 'prefixed' with the dfdl:prefixLengthType, the facets should mean the same thing.
Any thoughts/comments?
Note: daffodil PR about this: https://github.com/apache/daffodil/pull/1334 JIRA Issue: https://issues.apache.org/jira/browse/DAFFODIL-2660 -- dfdl-wg mailing list -- dfdl-wg@lists.ogf.org To unsubscribe send an email to dfdl-wg-leave@lists.ogf.org %(web_page_url)slistinfo/%(_internal_name)s
participants (2)
-
Mike Beckerle -
Steve Hanson