This is a static archive of the previous Open Grid Forum Redmine content management system saved from host redmine.ogf.org file /boards/15/topics/121?r=248 at Thu, 03 Nov 2022 23:30:52 GMT Inconsistency between textStandardDecimalSeparatorrules and textStandardNumberPattern rules. - Public Comments Archive - Open Grid Forum

Forums » #117 - DFDL v1.0 Revision »

Inconsistency between textStandardDecimalSeparatorrules and textStandardNumberPattern rules.

Added by Alex Wood about 9 years ago

For an integer type erata 2.27 added the rule that textStandardDecimalSeparator should be ignored.
However no such limitation was added for the decimal separator designator in the textStandardNumberPattern property.
This leads the case where you can set a textStandardNumberPattern of "0.0" on an integer field but not have an in scope textStandardDecimalSeparator with which to resolve it.

It think the two ought to be consistent.

Either an integer type should be able to have a textStandardDecimalSeparator for when textStandardNumberPattern contains '.' (and presumably the result would have to be a logical integer). (pre erata 2.27 behaviour)
or
when the type was an integer then textStandardDecimalSeparator should be ignored and textStandardNumberPattern must not contain a decimal separator designator '.'


Replies (7)

RE: Inconsistency between textStandardDecimalSeparatorrules and textStandardNumberPattern rules. - Added by Steve Hanson almost 9 years ago

To help resolve this, here is errata 2.27:

2.27. Section 13.6. textStandardDecimalSeparator must be ignored when the logical type is not decimal/float/double.

RE: Inconsistency between textStandardDecimalSeparatorrules and textStandardNumberPattern rules. - Added by Michael Beckerle almost 9 years ago

Note: typo in this public comment - textStandardNumberPattern the property name is textNumberPattern.

Action 244 - RE: Inconsistency between textStandardDecimalSeparatorrules and textStandardNumberPattern rules. - Added by Michael Beckerle almost 9 years ago

Conservative decision ignoring implementation concerns would be to disallow "." in textNumberPattern for integer types.

However, since many/most implementations will want to use the ICU libraries, there is an issue of how those libraries behave.

ICU behavior even when strict, is to always look at decimal separators, and exponent indicators, or @ (significant digits) indicators.

One suggestion given this is to revise Errata 2.27 - remove restrictions on textNumberPattern for simple types.

Action 244 to investigate and resolve this issue.

Resolved: Inconsistency between textStandardDecimalSeparatorrules and textStandardNumberPattern rules. - Added by Steve Hanson almost 9 years ago

For simplicity of rule and ease of implementation, it is decided that the textNumberPattern for an integer type is allowed to contain '.', 'V' and 'P', the same as a decimal. If the data contains fractional decimal digits other than '0' then a type conversion error will result, otherwise the value is allowed. This has the effect ofm reversing errata 2.27. Whether the textStandardDecimalSeparator is required is therefore dependent on the pattern not the type.

Resolved: Inconsistency between textStandardDecimalSeparatorrules and textStandardNumberPattern rules. - Added by Steve Hanson over 8 years ago

Updated erratum 2.27 in experience document 1 (the erratum is reversed).

(1-7/7)

This is a static archive of the previous Open Grid Forum Redmine content management system saved from host redmine.ogf.org file /boards/15/topics/121?r=248 at Thu, 03 Nov 2022 23:30:52 GMT