Steve 1) Infoset output for calendar types: The infoset output for all simple types is given in section 4.1.2 in the description of the [dataValue] member. It just says it is a value in the value space of the simple type as defined by the XML Schema 1.0 spec. http://www.w3.org/TR/2004/REC-xmlschema-2-20041028/datatypes.html Your description looks correct. 2) Implicit calendar patterns. The point of calendarPattern 'implicit' is to provide a format that has a good chance of being applicable to real-world formats. Leaving timezone out of the implicit pattern for xs:date makes sense, as although XSD allows it, very few date-only formats will carry a timezone. Leaving timezone out of the implicit pattern for xs:dateTime was a judgement call that could have gone either way. Given that the modeler always has the option of using an explicit pattern, and IBM's implementation is already in the field, I am happy to stay with the specification as it stands. It sounds like the IBM tests are not correct in providing -08:00 in the data, they should be providing -0800. For some reason both formats are being accepted by IBM DFDL when ZZZ is used. I suspect this is ICU behaviour because we just call ICU with the pattern. I'll need to look into this further. We have an open ICU ticket #472 which is the subject of an open DFDL WG action to clarify leniency when parsing, but it does not list any leniency around Z handling. Errata 2.127 was recently taken to change the implicit pattern for xs:date to use single Z instead of ZZZ, to match ICU preferred behaviour for the Z symbol. There are several other errata that affect calendar processing, so please refer to the errata document on Redmine @ http://redmine.ogf.org/dmsf/dfdl-wg?folder_id=5485. Also note that the x and X symbols are not supported by the DFDL 1.0 specification as it currently stands. HTH Regards Steve Hanson Architect, IBM Data Format Description Language (DFDL) Co-Chair, OGF DFDL Working Group IBM SWG, Hursley, UK smh@uk.ibm.com tel:+44-1962-815848 From: Tim Kimber/UK/IBM@IBMGB To: Steve Lawrence <slawrence@tresys.com>, Cc: DFDL-WG <dfdl-wg@ogf.org>, dfdl-wg-bounces@ogf.org Date: 15/04/2013 09:42 Subject: Re: [DFDL-WG] More Date/Time/DateTime Clarifications Sent by: dfdl-wg-bounces@ogf.org In XML Schema, all of the calendar types have a timezone - ncluding xs:date. I don't know why the specification omits the time zone for xs:date and xs:dateTime - I think they should both include a time zone unless there is a good reason not to. regards, Tim Kimber, DFDL Team, Hursley, UK Internet: kimbert@uk.ibm.com Tel. 01962-816742 Internal tel. 37246742 From: Steve Lawrence <slawrence@tresys.com> To: DFDL-WG <dfdl-wg@ogf.org>, Date: 12/04/2013 21:08 Subject: [DFDL-WG] More Date/Time/DateTime Clarifications Sent by: dfdl-wg-bounces@ogf.org 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 -- dfdl-wg mailing list dfdl-wg@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 -- dfdl-wg mailing list dfdl-wg@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