You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@daffodil.apache.org by Attila Horvath <at...@gmail.com> on 2022/03/14 16:38:50 UTC
string to integer conversion w/ leading blanks fails
ALCON
Can someone pls suggest a way to convert string to integer if/when leading
blanks are present?
My attempts are failing - see attached pdf for more details.
Thx in advance
Attila
Re: string to integer conversion w/ leading blanks fails
Posted by Mike Beckerle <mb...@apache.org>.
There are many people asking for various fixes to Daffodil.
You can certainly get the priority of a particular fix/feature increased by
advocating for it on dev or users mailing lists.
But,... (my recruiting hat on now... you know what is coming...) you could
also contribute the fix (and a test case).
Daffodil is open source.
Fixing the text->number constructors so that whitespace is tolerated when
creating numeric values is an easy fix.
Adding additional functions is also pretty easy. We have used that as a
learning exercise for new contributors in the past.
We actually consciously try not to rapid-fix such easy things, because
well, we want to encourage more contributors to Daffodil.
That doesn't mean an existing contributor won't fix the issue. It just
means we will attempt to recruit you to contribute the fix yourself first.
(i.e., this email :-)
And as far as the DFDL language standard goes. That workgroup now operates
on the principle where experience with an implementation of a new
capability must first be documented before it can be incorporated into the
standard.
On Fri, Mar 18, 2022 at 6:50 AM Attila Horvath <at...@gmail.com>
wrote:
> Mike
>
> Appreciate the suggested workaround. I did incorporate/test your snippet
> per Mar 16, 2022 at 12:21 PM [below] w/ following anticipated results:
>
> [1]Satellite numbers w/ leading whitespace(s) yields lossless unparse
> results.
> [2]Satellite numbers w/ leading zero(s) or whitespace(s)+zero(s) yield
> unparse results that are 'numerically' equivalent |HOWEVER| unparsed target
> ASCII file fails to compare w/ parsed source ASCII file due to
> <<<dfdl:textNumberPattern="####0">>> formatting that trims leading
> irrelevant characters - see attached parse/source and unparse/target files.
> NB "00000" formatting yields opposite results by trimming leading
> whitspace(s).
>
> The issue/concern of 'lossless' parse/unparse processing for our
> organization is fundamental. Our organization has no control over
> customers' [legacy] pre-/post- processes |AND| the format of input data.
> Ergo lossless end-to-end data transformation is essential b/c if/when
> source/target data fail to compare, we're placed in the untenable position
> of explaining differences on case by case basis.
>
> The impetus/urgency for my questions below re: ticket is that producing
> lossless end-to-end data transformation results via string processing with
> suite of XPATH functions is more important/suitable than yielding
> numerically 'equivalent' results.
>
> Thx - Attila
>
> On Fri, Mar 18, 2022 at 5:12 AM Attila Horvath <at...@gmail.com>
> wrote:
>
>> I know you're preparing to release 3.3.0.
>>
>> When do think this issue might be resolved? Which point release are you
>> targeting?
>>
>> On a related subject, Daffodil implements a subset of XPATH function.
>> Might dev-team consider implementing all XPATH functions in lieu of
>> workarounds?
>>
>> Thx in advance - Attila
>>
>> On Wed, Mar 16, 2022 at 12:26 PM Mike Beckerle <mb...@apache.org>
>> wrote:
>>
>>> Created https://issues.apache.org/jira/browse/DAFFODIL-2676
>>>
>>> On Wed, Mar 16, 2022 at 12:21 PM Mike Beckerle <mb...@apache.org>
>>> wrote:
>>>
>>> > Ok, I found the attachment. Sorry for the delay.
>>> >
>>> > The challenge here is you are thinking the
>>> > xs:unsignedInt(../Line1.02-Satellite) call will tolerate whitespace.
>>> Which
>>> > it seems they do not.
>>> >
>>> > I think this is a Daffodil bug, as the constructors like xs:unsignedInt
>>> > are supposed to work like they do in XPath, and the XPath functions
>>> spec
>>> > says when converting from strings, that whitespace normalization
>>> applies -
>>> > which trims all leading and trailing whitespace. It's less clear
>>> > about whether interior whitespace is collapsed, but definitely
>>> > leading/trailing seem to be trimmed.
>>> >
>>> > So I'll add a JIRA ticket about this.
>>> >
>>> > For how to work around, I suggest parsing the satellite field not as a
>>> > string, but as an unsignedInt from the start.
>>> >
>>> > So like:
>>> >
>>> > <xs:element name="satellite-num-range" type="xs:unsignedInt"
>>> > dfdl:lengthKind="explicit" dfdl:length="5"
>>> > dfdl:textTrimKind="padChar" dfdl:textPadKind="padChar"
>>> > dfdl:textNumberPadCharacter="%SP;" dfdl:textNumberJustification="right"
>>> > dfdl:textNumberPattern="####0"/>
>>> >
>>> > I didn't run this, but I think this will remove leading spaces, and add
>>> > leading spaces to your 5 character element.
>>> >
>>> > Another way to express this, since you need only leading padding is
>>> this:
>>> >
>>> > <xs:element name="satellite-num-range" type="xs:unsignedInt"
>>> > dfdl:lengthKind="explicit" dfdl:length="5"
>>> > dfdl:textNumberPattern="* ####0"/>
>>> >
>>> > In that textNumberPattern the "* " means spaces are the pad character
>>> to
>>> > be used, and when there is no digit for the position of a "#" then the
>>> pad
>>> > character from the pattern (not the textNumberPadCharacter) is used.
>>> >
>>> > Both kinds of padding can be used together E.g., so you could have
>>> number
>>> > text right justified in a fixed-length field of width 6, using "*" to
>>> pad
>>> > to width 5 so that you can get " **123".
>>> >
>>> > <xs:element name="starPadNum" type="xs:unsignedInt"
>>> > dfdl:lengthKind="explicit" dfdl:length="6"
>>> > dfdl:textTrimKind="padChar" dfdl:textPadKind="padChar"
>>> > dfdl:textNumberPadCharacter="%SP;" dfdl:textNumberJustification="right"
>>> > dfdl:textNumberPattern="* ####0"/>
>>> >
>>> > I didn't run these, but this is, I believe, how it is supposed to work.
>>> >
>>> >
>>> >
>>>
>>>
Re: string to integer conversion w/ leading blanks fails
Posted by Attila Horvath <at...@gmail.com>.
Mike
Appreciate the suggested workaround. I did incorporate/test your snippet
per Mar 16, 2022 at 12:21 PM [below] w/ following anticipated results:
[1]Satellite numbers w/ leading whitespace(s) yields lossless unparse
results.
[2]Satellite numbers w/ leading zero(s) or whitespace(s)+zero(s) yield
unparse results that are 'numerically' equivalent |HOWEVER| unparsed target
ASCII file fails to compare w/ parsed source ASCII file due to
<<<dfdl:textNumberPattern="####0">>> formatting that trims leading
irrelevant characters - see attached parse/source and unparse/target files.
NB "00000" formatting yields opposite results by trimming leading
whitspace(s).
The issue/concern of 'lossless' parse/unparse processing for our
organization is fundamental. Our organization has no control over
customers' [legacy] pre-/post- processes |AND| the format of input data.
Ergo lossless end-to-end data transformation is essential b/c if/when
source/target data fail to compare, we're placed in the untenable position
of explaining differences on case by case basis.
The impetus/urgency for my questions below re: ticket is that producing
lossless end-to-end data transformation results via string processing with
suite of XPATH functions is more important/suitable than yielding
numerically 'equivalent' results.
Thx - Attila
On Fri, Mar 18, 2022 at 5:12 AM Attila Horvath <at...@gmail.com>
wrote:
> I know you're preparing to release 3.3.0.
>
> When do think this issue might be resolved? Which point release are you
> targeting?
>
> On a related subject, Daffodil implements a subset of XPATH function.
> Might dev-team consider implementing all XPATH functions in lieu of
> workarounds?
>
> Thx in advance - Attila
>
> On Wed, Mar 16, 2022 at 12:26 PM Mike Beckerle <mb...@apache.org>
> wrote:
>
>> Created https://issues.apache.org/jira/browse/DAFFODIL-2676
>>
>> On Wed, Mar 16, 2022 at 12:21 PM Mike Beckerle <mb...@apache.org>
>> wrote:
>>
>> > Ok, I found the attachment. Sorry for the delay.
>> >
>> > The challenge here is you are thinking the
>> > xs:unsignedInt(../Line1.02-Satellite) call will tolerate whitespace.
>> Which
>> > it seems they do not.
>> >
>> > I think this is a Daffodil bug, as the constructors like xs:unsignedInt
>> > are supposed to work like they do in XPath, and the XPath functions spec
>> > says when converting from strings, that whitespace normalization
>> applies -
>> > which trims all leading and trailing whitespace. It's less clear
>> > about whether interior whitespace is collapsed, but definitely
>> > leading/trailing seem to be trimmed.
>> >
>> > So I'll add a JIRA ticket about this.
>> >
>> > For how to work around, I suggest parsing the satellite field not as a
>> > string, but as an unsignedInt from the start.
>> >
>> > So like:
>> >
>> > <xs:element name="satellite-num-range" type="xs:unsignedInt"
>> > dfdl:lengthKind="explicit" dfdl:length="5"
>> > dfdl:textTrimKind="padChar" dfdl:textPadKind="padChar"
>> > dfdl:textNumberPadCharacter="%SP;" dfdl:textNumberJustification="right"
>> > dfdl:textNumberPattern="####0"/>
>> >
>> > I didn't run this, but I think this will remove leading spaces, and add
>> > leading spaces to your 5 character element.
>> >
>> > Another way to express this, since you need only leading padding is
>> this:
>> >
>> > <xs:element name="satellite-num-range" type="xs:unsignedInt"
>> > dfdl:lengthKind="explicit" dfdl:length="5"
>> > dfdl:textNumberPattern="* ####0"/>
>> >
>> > In that textNumberPattern the "* " means spaces are the pad character to
>> > be used, and when there is no digit for the position of a "#" then the
>> pad
>> > character from the pattern (not the textNumberPadCharacter) is used.
>> >
>> > Both kinds of padding can be used together E.g., so you could have
>> number
>> > text right justified in a fixed-length field of width 6, using "*" to
>> pad
>> > to width 5 so that you can get " **123".
>> >
>> > <xs:element name="starPadNum" type="xs:unsignedInt"
>> > dfdl:lengthKind="explicit" dfdl:length="6"
>> > dfdl:textTrimKind="padChar" dfdl:textPadKind="padChar"
>> > dfdl:textNumberPadCharacter="%SP;" dfdl:textNumberJustification="right"
>> > dfdl:textNumberPattern="* ####0"/>
>> >
>> > I didn't run these, but this is, I believe, how it is supposed to work.
>> >
>> >
>> >
>>
>>
Re: string to integer conversion w/ leading blanks fails
Posted by Attila Horvath <at...@gmail.com>.
I know you're preparing to release 3.3.0.
When do think this issue might be resolved? Which point release are you
targeting?
On a related subject, Daffodil implements a subset of XPATH function.
Might dev-team consider implementing all XPATH functions in lieu of
workarounds?
Thx in advance - Attila
On Wed, Mar 16, 2022 at 12:26 PM Mike Beckerle <mb...@apache.org> wrote:
> Created https://issues.apache.org/jira/browse/DAFFODIL-2676
>
> On Wed, Mar 16, 2022 at 12:21 PM Mike Beckerle <mb...@apache.org>
> wrote:
>
> > Ok, I found the attachment. Sorry for the delay.
> >
> > The challenge here is you are thinking the
> > xs:unsignedInt(../Line1.02-Satellite) call will tolerate whitespace.
> Which
> > it seems they do not.
> >
> > I think this is a Daffodil bug, as the constructors like xs:unsignedInt
> > are supposed to work like they do in XPath, and the XPath functions spec
> > says when converting from strings, that whitespace normalization applies
> -
> > which trims all leading and trailing whitespace. It's less clear
> > about whether interior whitespace is collapsed, but definitely
> > leading/trailing seem to be trimmed.
> >
> > So I'll add a JIRA ticket about this.
> >
> > For how to work around, I suggest parsing the satellite field not as a
> > string, but as an unsignedInt from the start.
> >
> > So like:
> >
> > <xs:element name="satellite-num-range" type="xs:unsignedInt"
> > dfdl:lengthKind="explicit" dfdl:length="5"
> > dfdl:textTrimKind="padChar" dfdl:textPadKind="padChar"
> > dfdl:textNumberPadCharacter="%SP;" dfdl:textNumberJustification="right"
> > dfdl:textNumberPattern="####0"/>
> >
> > I didn't run this, but I think this will remove leading spaces, and add
> > leading spaces to your 5 character element.
> >
> > Another way to express this, since you need only leading padding is this:
> >
> > <xs:element name="satellite-num-range" type="xs:unsignedInt"
> > dfdl:lengthKind="explicit" dfdl:length="5"
> > dfdl:textNumberPattern="* ####0"/>
> >
> > In that textNumberPattern the "* " means spaces are the pad character to
> > be used, and when there is no digit for the position of a "#" then the
> pad
> > character from the pattern (not the textNumberPadCharacter) is used.
> >
> > Both kinds of padding can be used together E.g., so you could have number
> > text right justified in a fixed-length field of width 6, using "*" to pad
> > to width 5 so that you can get " **123".
> >
> > <xs:element name="starPadNum" type="xs:unsignedInt"
> > dfdl:lengthKind="explicit" dfdl:length="6"
> > dfdl:textTrimKind="padChar" dfdl:textPadKind="padChar"
> > dfdl:textNumberPadCharacter="%SP;" dfdl:textNumberJustification="right"
> > dfdl:textNumberPattern="* ####0"/>
> >
> > I didn't run these, but this is, I believe, how it is supposed to work.
> >
> >
> >
>
>
Re: string to integer conversion w/ leading blanks fails
Posted by Steve Lawrence <sl...@apache.org>.
The fn:normalize-space function is not supported by DFDL. DFDL only
implements a subset of XPath. This link has the list of supported functions:
https://daffodil.apache.org/docs/dfdl/#_Toc62570222
The fn:count function returns the number of "Line1.02-Satellite"
elements in the infoset. It does not have anything to do with the value
of the element. In this case, the result of fn:count will always be 1
because that's the count of that element in the infoset. That is never
greater than 6999 and so the error path will not be hit.
On 3/16/22 2:00 PM, Attila Horvath wrote:
> Mike et al
>
> See dev/users mail list for attached PDF.
>
> In addition to unexpected <xs:unsignedInt> behavior, see unusual behavior re:
> fn:count
> dfdl:outputValueCalc ... if (~) then ~ else
>
> Attila
>
> On Wed, Mar 16, 2022 at 12:26 PM Mike Beckerle <mbeckerle@apache.org
> <ma...@apache.org>> wrote:
>
> Created https://issues.apache.org/jira/browse/DAFFODIL-2676
> <https://issues.apache.org/jira/browse/DAFFODIL-2676>
>
> On Wed, Mar 16, 2022 at 12:21 PM Mike Beckerle <mbeckerle@apache.org
> <ma...@apache.org>> wrote:
>
> > Ok, I found the attachment. Sorry for the delay.
> >
> > The challenge here is you are thinking the
> > xs:unsignedInt(../Line1.02-Satellite) call will tolerate whitespace. Which
> > it seems they do not.
> >
> > I think this is a Daffodil bug, as the constructors like xs:unsignedInt
> > are supposed to work like they do in XPath, and the XPath functions spec
> > says when converting from strings, that whitespace normalization applies -
> > which trims all leading and trailing whitespace. It's less clear
> > about whether interior whitespace is collapsed, but definitely
> > leading/trailing seem to be trimmed.
> >
> > So I'll add a JIRA ticket about this.
> >
> > For how to work around, I suggest parsing the satellite field not as a
> > string, but as an unsignedInt from the start.
> >
> > So like:
> >
> > <xs:element name="satellite-num-range" type="xs:unsignedInt"
> > dfdl:lengthKind="explicit" dfdl:length="5"
> > dfdl:textTrimKind="padChar" dfdl:textPadKind="padChar"
> > dfdl:textNumberPadCharacter="%SP;" dfdl:textNumberJustification="right"
> > dfdl:textNumberPattern="####0"/>
> >
> > I didn't run this, but I think this will remove leading spaces, and add
> > leading spaces to your 5 character element.
> >
> > Another way to express this, since you need only leading padding is this:
> >
> > <xs:element name="satellite-num-range" type="xs:unsignedInt"
> > dfdl:lengthKind="explicit" dfdl:length="5"
> > dfdl:textNumberPattern="* ####0"/>
> >
> > In that textNumberPattern the "* " means spaces are the pad character to
> > be used, and when there is no digit for the position of a "#" then the pad
> > character from the pattern (not the textNumberPadCharacter) is used.
> >
> > Both kinds of padding can be used together E.g., so you could have number
> > text right justified in a fixed-length field of width 6, using "*" to pad
> > to width 5 so that you can get " **123".
> >
> > <xs:element name="starPadNum" type="xs:unsignedInt"
> > dfdl:lengthKind="explicit" dfdl:length="6"
> > dfdl:textTrimKind="padChar" dfdl:textPadKind="padChar"
> > dfdl:textNumberPadCharacter="%SP;" dfdl:textNumberJustification="right"
> > dfdl:textNumberPattern="* ####0"/>
> >
> > I didn't run these, but this is, I believe, how it is supposed to work.
> >
> >
> >
> > On Tue, Mar 15, 2022 at 5:23 PM Attila Horvath
> <attila.j.horvath@gmail.com <ma...@gmail.com>>
> > wrote:
> >
> >> Attachment can be found on
> >> https://lists.apache.org/list.html?users@daffodil.apache.org
> <ht...@daffodil.apache.org> list.
> >> Not sure why it didn't show up on dev - I sent msg to both lists.
> >>
> >> On Tue, Mar 15, 2022 at 3:41 PM Mike Beckerle <mbeckerle@apache.org
> <ma...@apache.org>>
> >> wrote:
> >>
> >> > No attached PDF.
> >> >
> >> > Removal of blanks from a number would normally be by way of DFDL
> >> "padding"
> >> > and "trimming" properties.
> >> >
> >> > You need dfdl:textNumberJustification property, also textTrimKind,
> >> > textPadKind, textNumberPadCharacter.
> >> >
> >> > You can also use textNumberPattern to indicate that a number may have
> >> > leading spaces or zeros, but this is mostly about output when those
> >> leading
> >> > zeros are required.
> >> >
> >> > Padding on left == Right Justified
> >> > Padding on right == Left Justified
> >> > Padding around both sides = Center Justified.
> >> >
> >> >
> >> >
> >> > On Tue, Mar 15, 2022 at 8:53 AM Attila Horvath <
> >> attila.j.horvath@gmail.com <ma...@gmail.com>
> >> > >
> >> > wrote:
> >> >
> >> > > Ping... any assistance appreciated - thx
> >> > >
> >> > > ---------- Forwarded message ---------
> >> > > From: Attila Horvath <attila.j.horvath@gmail.com
> <ma...@gmail.com>>
> >> > > Date: Mon, Mar 14, 2022 at 12:38 PM
> >> > > Subject: string to integer conversion w/ leading blanks fails
> >> > > To: <users@daffodil.apache.org <ma...@daffodil.apache.org>>,
> <dev@daffodil.apache.org <ma...@daffodil.apache.org>>
> >> > >
> >> > >
> >> > > ALCON
> >> > >
> >> > > Can someone pls suggest a way to convert string to integer if/when
> >> > leading
> >> > > blanks are present?
> >> > >
> >> > > My attempts are failing - see attached pdf for more details.
> >> > >
> >> > > Thx in advance
> >> > >
> >> > > Attila
> >> > >
> >> >
> >>
> >
>
Re: string to integer conversion w/ leading blanks fails
Posted by Attila Horvath <at...@gmail.com>.
Mike et al
See dev/users mail list for attached PDF.
In addition to unexpected <xs:unsignedInt> behavior, see unusual behavior
re:
fn:count
dfdl:outputValueCalc ... if (~) then ~ else
Attila
On Wed, Mar 16, 2022 at 12:26 PM Mike Beckerle <mb...@apache.org> wrote:
> Created https://issues.apache.org/jira/browse/DAFFODIL-2676
>
> On Wed, Mar 16, 2022 at 12:21 PM Mike Beckerle <mb...@apache.org>
> wrote:
>
> > Ok, I found the attachment. Sorry for the delay.
> >
> > The challenge here is you are thinking the
> > xs:unsignedInt(../Line1.02-Satellite) call will tolerate whitespace.
> Which
> > it seems they do not.
> >
> > I think this is a Daffodil bug, as the constructors like xs:unsignedInt
> > are supposed to work like they do in XPath, and the XPath functions spec
> > says when converting from strings, that whitespace normalization applies
> -
> > which trims all leading and trailing whitespace. It's less clear
> > about whether interior whitespace is collapsed, but definitely
> > leading/trailing seem to be trimmed.
> >
> > So I'll add a JIRA ticket about this.
> >
> > For how to work around, I suggest parsing the satellite field not as a
> > string, but as an unsignedInt from the start.
> >
> > So like:
> >
> > <xs:element name="satellite-num-range" type="xs:unsignedInt"
> > dfdl:lengthKind="explicit" dfdl:length="5"
> > dfdl:textTrimKind="padChar" dfdl:textPadKind="padChar"
> > dfdl:textNumberPadCharacter="%SP;" dfdl:textNumberJustification="right"
> > dfdl:textNumberPattern="####0"/>
> >
> > I didn't run this, but I think this will remove leading spaces, and add
> > leading spaces to your 5 character element.
> >
> > Another way to express this, since you need only leading padding is this:
> >
> > <xs:element name="satellite-num-range" type="xs:unsignedInt"
> > dfdl:lengthKind="explicit" dfdl:length="5"
> > dfdl:textNumberPattern="* ####0"/>
> >
> > In that textNumberPattern the "* " means spaces are the pad character to
> > be used, and when there is no digit for the position of a "#" then the
> pad
> > character from the pattern (not the textNumberPadCharacter) is used.
> >
> > Both kinds of padding can be used together E.g., so you could have number
> > text right justified in a fixed-length field of width 6, using "*" to pad
> > to width 5 so that you can get " **123".
> >
> > <xs:element name="starPadNum" type="xs:unsignedInt"
> > dfdl:lengthKind="explicit" dfdl:length="6"
> > dfdl:textTrimKind="padChar" dfdl:textPadKind="padChar"
> > dfdl:textNumberPadCharacter="%SP;" dfdl:textNumberJustification="right"
> > dfdl:textNumberPattern="* ####0"/>
> >
> > I didn't run these, but this is, I believe, how it is supposed to work.
> >
> >
> >
> > On Tue, Mar 15, 2022 at 5:23 PM Attila Horvath <
> attila.j.horvath@gmail.com>
> > wrote:
> >
> >> Attachment can be found on
> >> https://lists.apache.org/list.html?users@daffodil.apache.org list.
> >> Not sure why it didn't show up on dev - I sent msg to both lists.
> >>
> >> On Tue, Mar 15, 2022 at 3:41 PM Mike Beckerle <mb...@apache.org>
> >> wrote:
> >>
> >> > No attached PDF.
> >> >
> >> > Removal of blanks from a number would normally be by way of DFDL
> >> "padding"
> >> > and "trimming" properties.
> >> >
> >> > You need dfdl:textNumberJustification property, also textTrimKind,
> >> > textPadKind, textNumberPadCharacter.
> >> >
> >> > You can also use textNumberPattern to indicate that a number may have
> >> > leading spaces or zeros, but this is mostly about output when those
> >> leading
> >> > zeros are required.
> >> >
> >> > Padding on left == Right Justified
> >> > Padding on right == Left Justified
> >> > Padding around both sides = Center Justified.
> >> >
> >> >
> >> >
> >> > On Tue, Mar 15, 2022 at 8:53 AM Attila Horvath <
> >> attila.j.horvath@gmail.com
> >> > >
> >> > wrote:
> >> >
> >> > > Ping... any assistance appreciated - thx
> >> > >
> >> > > ---------- Forwarded message ---------
> >> > > From: Attila Horvath <at...@gmail.com>
> >> > > Date: Mon, Mar 14, 2022 at 12:38 PM
> >> > > Subject: string to integer conversion w/ leading blanks fails
> >> > > To: <us...@daffodil.apache.org>, <de...@daffodil.apache.org>
> >> > >
> >> > >
> >> > > ALCON
> >> > >
> >> > > Can someone pls suggest a way to convert string to integer if/when
> >> > leading
> >> > > blanks are present?
> >> > >
> >> > > My attempts are failing - see attached pdf for more details.
> >> > >
> >> > > Thx in advance
> >> > >
> >> > > Attila
> >> > >
> >> >
> >>
> >
>
Re: string to integer conversion w/ leading blanks fails
Posted by Attila Horvath <at...@gmail.com>.
Mike et al
See dev/users mail list for attached PDF.
In addition to unexpected <xs:unsignedInt> behavior, see unusual behavior
re:
fn:count
dfdl:outputValueCalc ... if (~) then ~ else
Attila
On Wed, Mar 16, 2022 at 12:26 PM Mike Beckerle <mb...@apache.org> wrote:
> Created https://issues.apache.org/jira/browse/DAFFODIL-2676
>
> On Wed, Mar 16, 2022 at 12:21 PM Mike Beckerle <mb...@apache.org>
> wrote:
>
> > Ok, I found the attachment. Sorry for the delay.
> >
> > The challenge here is you are thinking the
> > xs:unsignedInt(../Line1.02-Satellite) call will tolerate whitespace.
> Which
> > it seems they do not.
> >
> > I think this is a Daffodil bug, as the constructors like xs:unsignedInt
> > are supposed to work like they do in XPath, and the XPath functions spec
> > says when converting from strings, that whitespace normalization applies
> -
> > which trims all leading and trailing whitespace. It's less clear
> > about whether interior whitespace is collapsed, but definitely
> > leading/trailing seem to be trimmed.
> >
> > So I'll add a JIRA ticket about this.
> >
> > For how to work around, I suggest parsing the satellite field not as a
> > string, but as an unsignedInt from the start.
> >
> > So like:
> >
> > <xs:element name="satellite-num-range" type="xs:unsignedInt"
> > dfdl:lengthKind="explicit" dfdl:length="5"
> > dfdl:textTrimKind="padChar" dfdl:textPadKind="padChar"
> > dfdl:textNumberPadCharacter="%SP;" dfdl:textNumberJustification="right"
> > dfdl:textNumberPattern="####0"/>
> >
> > I didn't run this, but I think this will remove leading spaces, and add
> > leading spaces to your 5 character element.
> >
> > Another way to express this, since you need only leading padding is this:
> >
> > <xs:element name="satellite-num-range" type="xs:unsignedInt"
> > dfdl:lengthKind="explicit" dfdl:length="5"
> > dfdl:textNumberPattern="* ####0"/>
> >
> > In that textNumberPattern the "* " means spaces are the pad character to
> > be used, and when there is no digit for the position of a "#" then the
> pad
> > character from the pattern (not the textNumberPadCharacter) is used.
> >
> > Both kinds of padding can be used together E.g., so you could have number
> > text right justified in a fixed-length field of width 6, using "*" to pad
> > to width 5 so that you can get " **123".
> >
> > <xs:element name="starPadNum" type="xs:unsignedInt"
> > dfdl:lengthKind="explicit" dfdl:length="6"
> > dfdl:textTrimKind="padChar" dfdl:textPadKind="padChar"
> > dfdl:textNumberPadCharacter="%SP;" dfdl:textNumberJustification="right"
> > dfdl:textNumberPattern="* ####0"/>
> >
> > I didn't run these, but this is, I believe, how it is supposed to work.
> >
> >
> >
> > On Tue, Mar 15, 2022 at 5:23 PM Attila Horvath <
> attila.j.horvath@gmail.com>
> > wrote:
> >
> >> Attachment can be found on
> >> https://lists.apache.org/list.html?users@daffodil.apache.org list.
> >> Not sure why it didn't show up on dev - I sent msg to both lists.
> >>
> >> On Tue, Mar 15, 2022 at 3:41 PM Mike Beckerle <mb...@apache.org>
> >> wrote:
> >>
> >> > No attached PDF.
> >> >
> >> > Removal of blanks from a number would normally be by way of DFDL
> >> "padding"
> >> > and "trimming" properties.
> >> >
> >> > You need dfdl:textNumberJustification property, also textTrimKind,
> >> > textPadKind, textNumberPadCharacter.
> >> >
> >> > You can also use textNumberPattern to indicate that a number may have
> >> > leading spaces or zeros, but this is mostly about output when those
> >> leading
> >> > zeros are required.
> >> >
> >> > Padding on left == Right Justified
> >> > Padding on right == Left Justified
> >> > Padding around both sides = Center Justified.
> >> >
> >> >
> >> >
> >> > On Tue, Mar 15, 2022 at 8:53 AM Attila Horvath <
> >> attila.j.horvath@gmail.com
> >> > >
> >> > wrote:
> >> >
> >> > > Ping... any assistance appreciated - thx
> >> > >
> >> > > ---------- Forwarded message ---------
> >> > > From: Attila Horvath <at...@gmail.com>
> >> > > Date: Mon, Mar 14, 2022 at 12:38 PM
> >> > > Subject: string to integer conversion w/ leading blanks fails
> >> > > To: <us...@daffodil.apache.org>, <de...@daffodil.apache.org>
> >> > >
> >> > >
> >> > > ALCON
> >> > >
> >> > > Can someone pls suggest a way to convert string to integer if/when
> >> > leading
> >> > > blanks are present?
> >> > >
> >> > > My attempts are failing - see attached pdf for more details.
> >> > >
> >> > > Thx in advance
> >> > >
> >> > > Attila
> >> > >
> >> >
> >>
> >
>
Re: string to integer conversion w/ leading blanks fails
Posted by Mike Beckerle <mb...@apache.org>.
Created https://issues.apache.org/jira/browse/DAFFODIL-2676
On Wed, Mar 16, 2022 at 12:21 PM Mike Beckerle <mb...@apache.org> wrote:
> Ok, I found the attachment. Sorry for the delay.
>
> The challenge here is you are thinking the
> xs:unsignedInt(../Line1.02-Satellite) call will tolerate whitespace. Which
> it seems they do not.
>
> I think this is a Daffodil bug, as the constructors like xs:unsignedInt
> are supposed to work like they do in XPath, and the XPath functions spec
> says when converting from strings, that whitespace normalization applies -
> which trims all leading and trailing whitespace. It's less clear
> about whether interior whitespace is collapsed, but definitely
> leading/trailing seem to be trimmed.
>
> So I'll add a JIRA ticket about this.
>
> For how to work around, I suggest parsing the satellite field not as a
> string, but as an unsignedInt from the start.
>
> So like:
>
> <xs:element name="satellite-num-range" type="xs:unsignedInt"
> dfdl:lengthKind="explicit" dfdl:length="5"
> dfdl:textTrimKind="padChar" dfdl:textPadKind="padChar"
> dfdl:textNumberPadCharacter="%SP;" dfdl:textNumberJustification="right"
> dfdl:textNumberPattern="####0"/>
>
> I didn't run this, but I think this will remove leading spaces, and add
> leading spaces to your 5 character element.
>
> Another way to express this, since you need only leading padding is this:
>
> <xs:element name="satellite-num-range" type="xs:unsignedInt"
> dfdl:lengthKind="explicit" dfdl:length="5"
> dfdl:textNumberPattern="* ####0"/>
>
> In that textNumberPattern the "* " means spaces are the pad character to
> be used, and when there is no digit for the position of a "#" then the pad
> character from the pattern (not the textNumberPadCharacter) is used.
>
> Both kinds of padding can be used together E.g., so you could have number
> text right justified in a fixed-length field of width 6, using "*" to pad
> to width 5 so that you can get " **123".
>
> <xs:element name="starPadNum" type="xs:unsignedInt"
> dfdl:lengthKind="explicit" dfdl:length="6"
> dfdl:textTrimKind="padChar" dfdl:textPadKind="padChar"
> dfdl:textNumberPadCharacter="%SP;" dfdl:textNumberJustification="right"
> dfdl:textNumberPattern="* ####0"/>
>
> I didn't run these, but this is, I believe, how it is supposed to work.
>
>
>
> On Tue, Mar 15, 2022 at 5:23 PM Attila Horvath <at...@gmail.com>
> wrote:
>
>> Attachment can be found on
>> https://lists.apache.org/list.html?users@daffodil.apache.org list.
>> Not sure why it didn't show up on dev - I sent msg to both lists.
>>
>> On Tue, Mar 15, 2022 at 3:41 PM Mike Beckerle <mb...@apache.org>
>> wrote:
>>
>> > No attached PDF.
>> >
>> > Removal of blanks from a number would normally be by way of DFDL
>> "padding"
>> > and "trimming" properties.
>> >
>> > You need dfdl:textNumberJustification property, also textTrimKind,
>> > textPadKind, textNumberPadCharacter.
>> >
>> > You can also use textNumberPattern to indicate that a number may have
>> > leading spaces or zeros, but this is mostly about output when those
>> leading
>> > zeros are required.
>> >
>> > Padding on left == Right Justified
>> > Padding on right == Left Justified
>> > Padding around both sides = Center Justified.
>> >
>> >
>> >
>> > On Tue, Mar 15, 2022 at 8:53 AM Attila Horvath <
>> attila.j.horvath@gmail.com
>> > >
>> > wrote:
>> >
>> > > Ping... any assistance appreciated - thx
>> > >
>> > > ---------- Forwarded message ---------
>> > > From: Attila Horvath <at...@gmail.com>
>> > > Date: Mon, Mar 14, 2022 at 12:38 PM
>> > > Subject: string to integer conversion w/ leading blanks fails
>> > > To: <us...@daffodil.apache.org>, <de...@daffodil.apache.org>
>> > >
>> > >
>> > > ALCON
>> > >
>> > > Can someone pls suggest a way to convert string to integer if/when
>> > leading
>> > > blanks are present?
>> > >
>> > > My attempts are failing - see attached pdf for more details.
>> > >
>> > > Thx in advance
>> > >
>> > > Attila
>> > >
>> >
>>
>
Re: string to integer conversion w/ leading blanks fails
Posted by Mike Beckerle <mb...@apache.org>.
Ah. I'm glad you found this workaround.
This technique you are using is something I have generally called "Modeling
Syntax As Data". Sometimes this is the best way to model this sort of
data. It is a very powerful technique.
As you have no-doubt noticed, you can't push these "syntax elements" down
into hidden groups. The whole point of them is they have to appear in the
infoset so as to express the information needed to properly preserve
aspects of the data.
Whitespace preservation is the most common place I've seen it needed.
Prefixed length binary integers are another example.
On Thu, Mar 24, 2022 at 1:22 PM Attila Horvath <at...@gmail.com>
wrote:
> ALCON
>
> Appreciate the following suggested workaround:
>
> <xs:element name="satellite-num-range" type="xs:unsignedInt"
> dfdl:lengthKind="explicit" dfdl:length="5"
> dfdl:textTrimKind="padChar" dfdl:textPadKind="padChar"
> dfdl:textNumberPadCharacter="%SP;" dfdl:textNumberJustification="right"
> dfdl:textNumberPattern="####0"/>
>
> The snippet above on implementation does work but doesn’t yield lossless
> unparse results which is still our goal.
>
> After [much] trial/error I came up w/ alternative approach which deals
> with leading whitespace/zeros but produces lossless parse/unparsed results:
> [image: image.png]
>
> The snipped above 1st instantiates an element of leading whitespace(s) on
> line #134.
>
> Given the satellite number is fixed length of 5 characters, the hidden
> group isolates the numerical digits based on the number of whitespace
> characters and instantiates an element ‘satellite-num-range’ of variable
> length.
>
> This allows lossless string processing and the ability to convert string
> to unsignedInt and avoid conversion error due to leading whitespace(s).
>
>
>
> Attila
>
>
> PS: if you can't see embedded image above, see attached PDF.
>
>
> On Wed, Mar 16, 2022 at 12:21 PM Mike Beckerle <mb...@apache.org>
> wrote:
>
>> Ok, I found the attachment. Sorry for the delay.
>>
>> The challenge here is you are thinking the
>> xs:unsignedInt(../Line1.02-Satellite) call will tolerate whitespace. Which
>> it seems they do not.
>>
>> I think this is a Daffodil bug, as the constructors like xs:unsignedInt
>> are
>> supposed to work like they do in XPath, and the XPath functions spec says
>> when converting from strings, that whitespace normalization applies -
>> which
>> trims all leading and trailing whitespace. It's less clear about whether
>> interior whitespace is collapsed, but definitely leading/trailing seem to
>> be trimmed.
>>
>> So I'll add a JIRA ticket about this.
>>
>> For how to work around, I suggest parsing the satellite field not as a
>> string, but as an unsignedInt from the start.
>>
>> So like:
>>
>> <xs:element name="satellite-num-range" type="xs:unsignedInt"
>> dfdl:lengthKind="explicit" dfdl:length="5"
>> dfdl:textTrimKind="padChar" dfdl:textPadKind="padChar"
>> dfdl:textNumberPadCharacter="%SP;" dfdl:textNumberJustification="right"
>> dfdl:textNumberPattern="####0"/>
>>
>> I didn't run this, but I think this will remove leading spaces, and add
>> leading spaces to your 5 character element.
>>
>> Another way to express this, since you need only leading padding is this:
>>
>> <xs:element name="satellite-num-range" type="xs:unsignedInt"
>> dfdl:lengthKind="explicit" dfdl:length="5"
>> dfdl:textNumberPattern="* ####0"/>
>>
>> In that textNumberPattern the "* " means spaces are the pad character to
>> be
>> used, and when there is no digit for the position of a "#" then the pad
>> character from the pattern (not the textNumberPadCharacter) is used.
>>
>> Both kinds of padding can be used together E.g., so you could have number
>> text right justified in a fixed-length field of width 6, using "*" to pad
>> to width 5 so that you can get " **123".
>>
>> <xs:element name="starPadNum" type="xs:unsignedInt"
>> dfdl:lengthKind="explicit" dfdl:length="6"
>> dfdl:textTrimKind="padChar" dfdl:textPadKind="padChar"
>> dfdl:textNumberPadCharacter="%SP;" dfdl:textNumberJustification="right"
>> dfdl:textNumberPattern="* ####0"/>
>>
>> I didn't run these, but this is, I believe, how it is supposed to work.
>>
>>
>>
>> On Tue, Mar 15, 2022 at 5:23 PM Attila Horvath <
>> attila.j.horvath@gmail.com>
>> wrote:
>>
>> > Attachment can be found on
>> > https://lists.apache.org/list.html?users@daffodil.apache.org list.
>> > Not sure why it didn't show up on dev - I sent msg to both lists.
>> >
>> > On Tue, Mar 15, 2022 at 3:41 PM Mike Beckerle <mb...@apache.org>
>> > wrote:
>> >
>> > > No attached PDF.
>> > >
>> > > Removal of blanks from a number would normally be by way of DFDL
>> > "padding"
>> > > and "trimming" properties.
>> > >
>> > > You need dfdl:textNumberJustification property, also textTrimKind,
>> > > textPadKind, textNumberPadCharacter.
>> > >
>> > > You can also use textNumberPattern to indicate that a number may have
>> > > leading spaces or zeros, but this is mostly about output when those
>> > leading
>> > > zeros are required.
>> > >
>> > > Padding on left == Right Justified
>> > > Padding on right == Left Justified
>> > > Padding around both sides = Center Justified.
>> > >
>> > >
>> > >
>> > > On Tue, Mar 15, 2022 at 8:53 AM Attila Horvath <
>> > attila.j.horvath@gmail.com
>> > > >
>> > > wrote:
>> > >
>> > > > Ping... any assistance appreciated - thx
>> > > >
>> > > > ---------- Forwarded message ---------
>> > > > From: Attila Horvath <at...@gmail.com>
>> > > > Date: Mon, Mar 14, 2022 at 12:38 PM
>> > > > Subject: string to integer conversion w/ leading blanks fails
>> > > > To: <us...@daffodil.apache.org>, <de...@daffodil.apache.org>
>> > > >
>> > > >
>> > > > ALCON
>> > > >
>> > > > Can someone pls suggest a way to convert string to integer if/when
>> > > leading
>> > > > blanks are present?
>> > > >
>> > > > My attempts are failing - see attached pdf for more details.
>> > > >
>> > > > Thx in advance
>> > > >
>> > > > Attila
>> > > >
>> > >
>> >
>>
>
Re: string to integer conversion w/ leading blanks fails
Posted by Attila Horvath <at...@gmail.com>.
ALCON
Appreciate the following suggested workaround:
<xs:element name="satellite-num-range" type="xs:unsignedInt"
dfdl:lengthKind="explicit" dfdl:length="5"
dfdl:textTrimKind="padChar" dfdl:textPadKind="padChar"
dfdl:textNumberPadCharacter="%SP;" dfdl:textNumberJustification="right"
dfdl:textNumberPattern="####0"/>
The snippet above on implementation does work but doesn’t yield lossless
unparse results which is still our goal.
After [much] trial/error I came up w/ alternative approach which deals with
leading whitespace/zeros but produces lossless parse/unparsed results:
[image: image.png]
The snipped above 1st instantiates an element of leading whitespace(s) on
line #134.
Given the satellite number is fixed length of 5 characters, the hidden
group isolates the numerical digits based on the number of whitespace
characters and instantiates an element ‘satellite-num-range’ of variable
length.
This allows lossless string processing and the ability to convert string to
unsignedInt and avoid conversion error due to leading whitespace(s).
Attila
PS: if you can't see embedded image above, see attached PDF.
On Wed, Mar 16, 2022 at 12:21 PM Mike Beckerle <mb...@apache.org> wrote:
> Ok, I found the attachment. Sorry for the delay.
>
> The challenge here is you are thinking the
> xs:unsignedInt(../Line1.02-Satellite) call will tolerate whitespace. Which
> it seems they do not.
>
> I think this is a Daffodil bug, as the constructors like xs:unsignedInt are
> supposed to work like they do in XPath, and the XPath functions spec says
> when converting from strings, that whitespace normalization applies - which
> trims all leading and trailing whitespace. It's less clear about whether
> interior whitespace is collapsed, but definitely leading/trailing seem to
> be trimmed.
>
> So I'll add a JIRA ticket about this.
>
> For how to work around, I suggest parsing the satellite field not as a
> string, but as an unsignedInt from the start.
>
> So like:
>
> <xs:element name="satellite-num-range" type="xs:unsignedInt"
> dfdl:lengthKind="explicit" dfdl:length="5"
> dfdl:textTrimKind="padChar" dfdl:textPadKind="padChar"
> dfdl:textNumberPadCharacter="%SP;" dfdl:textNumberJustification="right"
> dfdl:textNumberPattern="####0"/>
>
> I didn't run this, but I think this will remove leading spaces, and add
> leading spaces to your 5 character element.
>
> Another way to express this, since you need only leading padding is this:
>
> <xs:element name="satellite-num-range" type="xs:unsignedInt"
> dfdl:lengthKind="explicit" dfdl:length="5"
> dfdl:textNumberPattern="* ####0"/>
>
> In that textNumberPattern the "* " means spaces are the pad character to be
> used, and when there is no digit for the position of a "#" then the pad
> character from the pattern (not the textNumberPadCharacter) is used.
>
> Both kinds of padding can be used together E.g., so you could have number
> text right justified in a fixed-length field of width 6, using "*" to pad
> to width 5 so that you can get " **123".
>
> <xs:element name="starPadNum" type="xs:unsignedInt"
> dfdl:lengthKind="explicit" dfdl:length="6"
> dfdl:textTrimKind="padChar" dfdl:textPadKind="padChar"
> dfdl:textNumberPadCharacter="%SP;" dfdl:textNumberJustification="right"
> dfdl:textNumberPattern="* ####0"/>
>
> I didn't run these, but this is, I believe, how it is supposed to work.
>
>
>
> On Tue, Mar 15, 2022 at 5:23 PM Attila Horvath <attila.j.horvath@gmail.com
> >
> wrote:
>
> > Attachment can be found on
> > https://lists.apache.org/list.html?users@daffodil.apache.org list.
> > Not sure why it didn't show up on dev - I sent msg to both lists.
> >
> > On Tue, Mar 15, 2022 at 3:41 PM Mike Beckerle <mb...@apache.org>
> > wrote:
> >
> > > No attached PDF.
> > >
> > > Removal of blanks from a number would normally be by way of DFDL
> > "padding"
> > > and "trimming" properties.
> > >
> > > You need dfdl:textNumberJustification property, also textTrimKind,
> > > textPadKind, textNumberPadCharacter.
> > >
> > > You can also use textNumberPattern to indicate that a number may have
> > > leading spaces or zeros, but this is mostly about output when those
> > leading
> > > zeros are required.
> > >
> > > Padding on left == Right Justified
> > > Padding on right == Left Justified
> > > Padding around both sides = Center Justified.
> > >
> > >
> > >
> > > On Tue, Mar 15, 2022 at 8:53 AM Attila Horvath <
> > attila.j.horvath@gmail.com
> > > >
> > > wrote:
> > >
> > > > Ping... any assistance appreciated - thx
> > > >
> > > > ---------- Forwarded message ---------
> > > > From: Attila Horvath <at...@gmail.com>
> > > > Date: Mon, Mar 14, 2022 at 12:38 PM
> > > > Subject: string to integer conversion w/ leading blanks fails
> > > > To: <us...@daffodil.apache.org>, <de...@daffodil.apache.org>
> > > >
> > > >
> > > > ALCON
> > > >
> > > > Can someone pls suggest a way to convert string to integer if/when
> > > leading
> > > > blanks are present?
> > > >
> > > > My attempts are failing - see attached pdf for more details.
> > > >
> > > > Thx in advance
> > > >
> > > > Attila
> > > >
> > >
> >
>
Re: string to integer conversion w/ leading blanks fails
Posted by Mike Beckerle <mb...@apache.org>.
Ok, I found the attachment. Sorry for the delay.
The challenge here is you are thinking the
xs:unsignedInt(../Line1.02-Satellite) call will tolerate whitespace. Which
it seems they do not.
I think this is a Daffodil bug, as the constructors like xs:unsignedInt are
supposed to work like they do in XPath, and the XPath functions spec says
when converting from strings, that whitespace normalization applies - which
trims all leading and trailing whitespace. It's less clear about whether
interior whitespace is collapsed, but definitely leading/trailing seem to
be trimmed.
So I'll add a JIRA ticket about this.
For how to work around, I suggest parsing the satellite field not as a
string, but as an unsignedInt from the start.
So like:
<xs:element name="satellite-num-range" type="xs:unsignedInt"
dfdl:lengthKind="explicit" dfdl:length="5"
dfdl:textTrimKind="padChar" dfdl:textPadKind="padChar"
dfdl:textNumberPadCharacter="%SP;" dfdl:textNumberJustification="right"
dfdl:textNumberPattern="####0"/>
I didn't run this, but I think this will remove leading spaces, and add
leading spaces to your 5 character element.
Another way to express this, since you need only leading padding is this:
<xs:element name="satellite-num-range" type="xs:unsignedInt"
dfdl:lengthKind="explicit" dfdl:length="5"
dfdl:textNumberPattern="* ####0"/>
In that textNumberPattern the "* " means spaces are the pad character to be
used, and when there is no digit for the position of a "#" then the pad
character from the pattern (not the textNumberPadCharacter) is used.
Both kinds of padding can be used together E.g., so you could have number
text right justified in a fixed-length field of width 6, using "*" to pad
to width 5 so that you can get " **123".
<xs:element name="starPadNum" type="xs:unsignedInt"
dfdl:lengthKind="explicit" dfdl:length="6"
dfdl:textTrimKind="padChar" dfdl:textPadKind="padChar"
dfdl:textNumberPadCharacter="%SP;" dfdl:textNumberJustification="right"
dfdl:textNumberPattern="* ####0"/>
I didn't run these, but this is, I believe, how it is supposed to work.
On Tue, Mar 15, 2022 at 5:23 PM Attila Horvath <at...@gmail.com>
wrote:
> Attachment can be found on
> https://lists.apache.org/list.html?users@daffodil.apache.org list.
> Not sure why it didn't show up on dev - I sent msg to both lists.
>
> On Tue, Mar 15, 2022 at 3:41 PM Mike Beckerle <mb...@apache.org>
> wrote:
>
> > No attached PDF.
> >
> > Removal of blanks from a number would normally be by way of DFDL
> "padding"
> > and "trimming" properties.
> >
> > You need dfdl:textNumberJustification property, also textTrimKind,
> > textPadKind, textNumberPadCharacter.
> >
> > You can also use textNumberPattern to indicate that a number may have
> > leading spaces or zeros, but this is mostly about output when those
> leading
> > zeros are required.
> >
> > Padding on left == Right Justified
> > Padding on right == Left Justified
> > Padding around both sides = Center Justified.
> >
> >
> >
> > On Tue, Mar 15, 2022 at 8:53 AM Attila Horvath <
> attila.j.horvath@gmail.com
> > >
> > wrote:
> >
> > > Ping... any assistance appreciated - thx
> > >
> > > ---------- Forwarded message ---------
> > > From: Attila Horvath <at...@gmail.com>
> > > Date: Mon, Mar 14, 2022 at 12:38 PM
> > > Subject: string to integer conversion w/ leading blanks fails
> > > To: <us...@daffodil.apache.org>, <de...@daffodil.apache.org>
> > >
> > >
> > > ALCON
> > >
> > > Can someone pls suggest a way to convert string to integer if/when
> > leading
> > > blanks are present?
> > >
> > > My attempts are failing - see attached pdf for more details.
> > >
> > > Thx in advance
> > >
> > > Attila
> > >
> >
>
Re: string to integer conversion w/ leading blanks fails
Posted by Attila Horvath <at...@gmail.com>.
Attachment can be found on
https://lists.apache.org/list.html?users@daffodil.apache.org list.
Not sure why it didn't show up on dev - I sent msg to both lists.
On Tue, Mar 15, 2022 at 3:41 PM Mike Beckerle <mb...@apache.org> wrote:
> No attached PDF.
>
> Removal of blanks from a number would normally be by way of DFDL "padding"
> and "trimming" properties.
>
> You need dfdl:textNumberJustification property, also textTrimKind,
> textPadKind, textNumberPadCharacter.
>
> You can also use textNumberPattern to indicate that a number may have
> leading spaces or zeros, but this is mostly about output when those leading
> zeros are required.
>
> Padding on left == Right Justified
> Padding on right == Left Justified
> Padding around both sides = Center Justified.
>
>
>
> On Tue, Mar 15, 2022 at 8:53 AM Attila Horvath <attila.j.horvath@gmail.com
> >
> wrote:
>
> > Ping... any assistance appreciated - thx
> >
> > ---------- Forwarded message ---------
> > From: Attila Horvath <at...@gmail.com>
> > Date: Mon, Mar 14, 2022 at 12:38 PM
> > Subject: string to integer conversion w/ leading blanks fails
> > To: <us...@daffodil.apache.org>, <de...@daffodil.apache.org>
> >
> >
> > ALCON
> >
> > Can someone pls suggest a way to convert string to integer if/when
> leading
> > blanks are present?
> >
> > My attempts are failing - see attached pdf for more details.
> >
> > Thx in advance
> >
> > Attila
> >
>
Re: string to integer conversion w/ leading blanks fails
Posted by Mike Beckerle <mb...@apache.org>.
No attached PDF.
Removal of blanks from a number would normally be by way of DFDL "padding"
and "trimming" properties.
You need dfdl:textNumberJustification property, also textTrimKind,
textPadKind, textNumberPadCharacter.
You can also use textNumberPattern to indicate that a number may have
leading spaces or zeros, but this is mostly about output when those leading
zeros are required.
Padding on left == Right Justified
Padding on right == Left Justified
Padding around both sides = Center Justified.
On Tue, Mar 15, 2022 at 8:53 AM Attila Horvath <at...@gmail.com>
wrote:
> Ping... any assistance appreciated - thx
>
> ---------- Forwarded message ---------
> From: Attila Horvath <at...@gmail.com>
> Date: Mon, Mar 14, 2022 at 12:38 PM
> Subject: string to integer conversion w/ leading blanks fails
> To: <us...@daffodil.apache.org>, <de...@daffodil.apache.org>
>
>
> ALCON
>
> Can someone pls suggest a way to convert string to integer if/when leading
> blanks are present?
>
> My attempts are failing - see attached pdf for more details.
>
> Thx in advance
>
> Attila
>
Re: string to integer conversion w/ leading blanks fails
Posted by Mike Beckerle <mb...@apache.org>.
No attached PDF.
Removal of blanks from a number would normally be by way of DFDL "padding"
and "trimming" properties.
You need dfdl:textNumberJustification property, also textTrimKind,
textPadKind, textNumberPadCharacter.
You can also use textNumberPattern to indicate that a number may have
leading spaces or zeros, but this is mostly about output when those leading
zeros are required.
Padding on left == Right Justified
Padding on right == Left Justified
Padding around both sides = Center Justified.
On Tue, Mar 15, 2022 at 8:53 AM Attila Horvath <at...@gmail.com>
wrote:
> Ping... any assistance appreciated - thx
>
> ---------- Forwarded message ---------
> From: Attila Horvath <at...@gmail.com>
> Date: Mon, Mar 14, 2022 at 12:38 PM
> Subject: string to integer conversion w/ leading blanks fails
> To: <us...@daffodil.apache.org>, <de...@daffodil.apache.org>
>
>
> ALCON
>
> Can someone pls suggest a way to convert string to integer if/when leading
> blanks are present?
>
> My attempts are failing - see attached pdf for more details.
>
> Thx in advance
>
> Attila
>
Fwd: string to integer conversion w/ leading blanks fails
Posted by Attila Horvath <at...@gmail.com>.
Ping... any assistance appreciated - thx
---------- Forwarded message ---------
From: Attila Horvath <at...@gmail.com>
Date: Mon, Mar 14, 2022 at 12:38 PM
Subject: string to integer conversion w/ leading blanks fails
To: <us...@daffodil.apache.org>, <de...@daffodil.apache.org>
ALCON
Can someone pls suggest a way to convert string to integer if/when leading
blanks are present?
My attempts are failing - see attached pdf for more details.
Thx in advance
Attila
Fwd: string to integer conversion w/ leading blanks fails
Posted by Attila Horvath <at...@gmail.com>.
Ping... any assistance appreciated - thx
---------- Forwarded message ---------
From: Attila Horvath <at...@gmail.com>
Date: Mon, Mar 14, 2022 at 12:38 PM
Subject: string to integer conversion w/ leading blanks fails
To: <us...@daffodil.apache.org>, <de...@daffodil.apache.org>
ALCON
Can someone pls suggest a way to convert string to integer if/when leading
blanks are present?
My attempts are failing - see attached pdf for more details.
Thx in advance
Attila