April 2013 - dfdl-wg - lists.ogf.org

Broadcast: OGF DFDL WG Call (30 Apr 15:00 GDT in DE3S09)
by Steve Hanson 23 Apr '13

23 Apr '13

OGF DFDL WG weekly call dial-in details. Passcode for Participants: 5381214 Canada Toll-Free 888-426-6840 China Toll-Free 10-800-711-1071 CHINA NETCOM GROUP USERS China Toll-Free 10-800-110-0996 CHINA TELECOM SOUTH USERS France Toll-Free 0800-94-0558 Germany Toll-Free 0800-000-1018 India Toll-Free 000-800-100-1176 Ireland Toll-Free 1-800-943-427 Israel Toll-Free 1-809-417-783 United Kingdom Caller Paid 0-20-30596451 United Kingdom Toll-Free 0800-368-0638 USA Caller Paid 215-861-6239 USA Toll-Free 888-426-6840 Other international numbers available - e-mail smh(a)uk.ibm.com. OGF DFDL Home: http://www.ogf.org/dfdl Redmine DFDL: http://redmine.ogf.org/projects/dfdl-wg

1 0

Re: [DFDL-WG] ICU and rounding for fractional seconds
by Steve Hanson 23 Apr '13

23 Apr '13

Agreed that DFDL should truncate not round. Errata taken. Regards Steve Hanson Architect, IBM Data Format Description Language (DFDL) Co-Chair, OGF DFDL Working Group IBM SWG, Hursley, UK smh(a)uk.ibm.com tel:+44-1962-815848 From: Steve Hanson/UK/IBM To: Mike Beckerle <mbeckerle.dfdl(a)gmail.com>, Cc: dfdl-wg(a)ogf.org Date: 15/04/2013 10:38 Subject: Re: [DFDL-WG] ICU and rounding for fractional seconds Mike I suspect that the statement about rounding of fractional seconds was introduced before the ICU behaviour was realised. We should go along with the ICU behaviour for ease of implementation. I'll raise at the next DFDL WG call, and get a clarification from ICU in the meantime. Regards Steve Hanson Architect, IBM Data Format Description Language (DFDL) Co-Chair, OGF DFDL Working Group IBM SWG, Hursley, UK smh(a)uk.ibm.com tel:+44-1962-815848 From: Mike Beckerle <mbeckerle.dfdl(a)gmail.com> To: dfdl-wg(a)ogf.org, Date: 12/04/2013 15:54 Subject: [DFDL-WG] ICU and rounding for fractional seconds Sent by: dfdl-wg-bounces(a)ogf.org Steve Lawrence on the Daffodil team has been implementing the date & time features. He has identified this issue: ICU doesn't support rounding, in fact they explicitly state rounding is not performed. From the javadoc: FieldPosition selector for 'S' field alignment, corresponding to the Calendar.MILLISECOND field. Note: Time formats that use 'S' can display a maximum of three significant digits for fractional seconds, corresponding to millisecond resolution and a fractional seconds sub-pattern of SSS. If the sub-pattern is S or SS, the fractional seconds value will be truncated (not rounded) to the number of display places specified. If the fractional seconds sub-pattern is longer than SSS, the additional display places will be filled with zeros. Are we reading the DFDL spec right? In regards to fractional seconds, it says: Round up rounding must occur when converting between external and internal representations. Does this mean that a time of 01:02:03.0019 should be represented as 01:02:03.002 in the infoset rather than 01:02:03.001? I don't think ICU supports that, and I thought DFDL attempted to fit as closely with ICU as possible, so this seems an odd change from ICU. -- dfdl-wg mailing list dfdl-wg(a)ogf.org https://www.ogf.org/mailman/listinfo/dfdl-wg Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU

1 0

OGF DFDL WG Call Agenda 2013-04-23
by Steve Hanson 22 Apr '13

22 Apr '13

Please find agenda for call on Redmine at http://redmine.ogf.org/dmsf_files/13070?download= Regards Steve Hanson Architect, IBM Data Format Description Language (DFDL) Co-Chair, OGF DFDL Working Group IBM SWG, Hursley, UK smh(a)uk.ibm.com tel:+44-1962-815848

1 0

AUTO: Sunil Dandamudi is out of the office (returning 04/19/2013)
by Sunil Dandamudi 18 Apr '13

18 Apr '13

I am out of the office until 04/19/2013. Note: This is an automated response to your message "dfdl-wg Digest, Vol 82, Issue 12" sent on 04/18/2013 10:00:01. This is the only notification you will receive while this person is away.

1 0

DFDL occurs properties on global elements
by Steve Hanson 17 Apr '13

17 Apr '13

Some more thoughts on this. Even if 4 is changed to a schema definition error, the normal scoping rules would mean that an occurs property could still be picked up from a global element if either the global element use dfdl:ref which pulled in an occurs property, or if the element ref and it's schema were totally silent about an occurs property but a dfdl:format in the global element's schema wasn't silent so the global element picked up a default. As well as the SDE we'd need to make it clear that properties in 4 must not be picked up from the global element's scope. ---------------------------------------------- Errata 3.8 clarifies what action a DFDL processor should take when it encounters an object that explicitly carries properties that are not relevant to the object, as follows: 1 Property not applicable to the object’s kind. Schema definition error. Example is lengthKind on xs:sequence. 2 Property not applicable because of simple type. Warning. Example is calendarPatternKind on xs:string. 3 Property not applicable because of another DFDL property setting. Warning. Example is binaryNumberRep when representation is text 4 Property not applicable because object is global. Warning (optional). Example is occursCountKind on a global xs:element. I am starting to question whether 4 is the correct behaviour. I think this should be a schema definition error and not a warning because the property becomes applicable for an element reference that refers to that global element. It is a different situation from the other warning cases 2 & 3, where the test is made once scoping rules are applied, and the property is therefore not applicable. Thoughts? Regards Steve Hanson Architect, IBM Data Format Description Language (DFDL) Co-Chair, OGF DFDL Working Group IBM SWG, Hursley, UK smh(a)uk.ibm.com tel:+44-1962-815848 Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU

1 0

DFDL occurs properties on global elements
by Steve Hanson 16 Apr '13

16 Apr '13

Errata 3.8 clarifies what action a DFDL processor should take when it encounters an object that explicitly carries properties that are not relevant to the object, as follows: 1 Property not applicable to the object’s kind. Schema definition error. Example is lengthKind on xs:sequence. 2 Property not applicable because of simple type. Warning. Example is calendarPatternKind on xs:string. 3 Property not applicable because of another DFDL property setting. Warning. Example is binaryNumberRep when representation is text 4 Property not applicable because object is global. Warning (optional). Example is occursCountKind on a global xs:element. I am starting to question whether 4 is the correct behaviour. I think this should be a schema definition error and not a warning because the property becomes applicable for an element reference that refers to that global element. It is a different situation from the other warning cases 2 & 3, where the test is made once scoping rules are applied, and the property is therefore not applicable. Thoughts? Regards Steve Hanson Architect, IBM Data Format Description Language (DFDL) Co-Chair, OGF DFDL Working Group IBM SWG, Hursley, UK smh(a)uk.ibm.com tel:+44-1962-815848 Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU

1 0

Cancelled: OGF DFDL WG Call
by Steve Hanson 16 Apr '13

16 Apr '13

Steve is at a conference

1 0

ICU and rounding for fractional seconds
by Mike Beckerle 15 Apr '13

15 Apr '13

Steve Lawrence on the Daffodil team has been implementing the date & time features. He has identified this issue: ICU doesn't support rounding, in fact they explicitly state rounding is not performed. From the javadoc: FieldPosition selector for 'S' field alignment, corresponding to the Calendar.MILLISECOND field. Note: Time formats that use 'S' can display a maximum of three significant digits for fractional seconds, corresponding to millisecond resolution and a fractional seconds sub-pattern of SSS. If the sub-pattern is S or SS, the fractional seconds value will be truncated (not rounded) to the number of display places specified. If the fractional seconds sub-pattern is longer than SSS, the additional display places will be filled with zeros. Are we reading the DFDL spec right? In regards to fractional seconds, it says: Round up rounding must occur when converting between external and internal representations. Does this mean that a time of 01:02:03.0019 should be represented as 01:02:03.002 in the infoset rather than 01:02:03.001? I don't think ICU supports that, and I thought DFDL attempted to fit as closely with ICU as possible, so this seems an odd change from ICU.

2 1

More Date/Time/DateTime Clarifications
by Steve Lawrence 15 Apr '13

15 Apr '13

We need a couple more clarifications on implementing date/time/dateTime in Daffodil. 1) What is the expected infoset output? The spec seems to be silent on this issue. Based on some tests we received from IBM, it looks like this makes sense: xs:date = uuuu-MM-ddxxx xs:time = HH:mm:ss.SSSSSSxxx xs:dateTime = uuuu-MM-dd'T'HH:mm:ss.SSSSSSxxx Points of interest: - uuuu instead of yyyy. The u allows for negative years, which is needed to represent BC dates - There are 6 significant figures for fractional seconds - Timezone is represented as xxx, since UTC is represented as +00:00 instead of 'Z' in the IBM tests we have Does this seem correct? 2) We would like some confirmation on the patterns for calendarPatternKind="implicit"? The current spec has: xs:date = yyyy-MM-dd xs:time = HH:mm:ssZZZ xs:dateTime = yyyy-MM-dd'T'HH:mm:ss The IBM tests we have match these patterns except for the timezone pattern for xs:time. The ZZZ pattern matches -0800, however, the IBM test we have parse -08:00. This could be represented with a few different patterns (e.g. ZZZZZ, XXX, xxx, xxxxx). We're unsure if the IBM tests are incorrect of if the spec needs to be updated. It also seems odd to me that the xs:time pattern has a timezone whereas dateTime does not. I'm not arguing it's wrong, just that it's not intuitive to me. Note that we don't have IBM's tool set up yet, so we can't verify if the tests we have actually represent IBM behavior. Thanks, - Steve

3 2

Cancelled: OGF DFDL WG Call
by Steve Hanson 12 Apr '13

12 Apr '13

Mike is on holiday

1 0