Tim, If a user wants a calendar type in his infoset for a 4 digit year, the recommendation would be to use a calendar pattern of 'YYYY'. The missing components get defaulted to values from the Unix epoch. That's much easier than using inputValueCalc (which would only be necessary if he wanted values other than the Unix epoch). Bearing that in mind, allowing the 'Year' and 'Year and month' granularities is not unnatural. On balance I think it is easier just to say that DFDL 'I' symbol supports all the granularities, and therefore all the W3C ISO8601 profile. Regards Steve Hanson Architect, 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 To: Steve Hanson/UK/IBM@IBMGB Cc: dfdl-wg@ogf.org, dfdl-wg-bounces@ogf.org Date: 16/01/2012 10:00 Subject: Re: [DFDL-WG] Proposed spec errata for calendarPattern I and T symbols I would be in favour of the behaviour listed under 'Alternatives'. If DFDL doesn't support gYear, gYearMonth etc then DFDL users should model the various parts of the type as integers/strings. They can always use XPath constructors with InputValueCalc if they really need to handle these types as calendar types. regards, Tim Kimber, Common Transformation Team, Hursley, UK Internet: kimbert@uk.ibm.com Tel. 01962-816742 Internal tel. 246742 From: Steve Hanson/UK/IBM@IBMGB To: dfdl-wg@ogf.org Date: 16/01/2012 05:05 Subject: [DFDL-WG] Proposed spec errata for calendarPattern I and T symbols Sent by: dfdl-wg-bounces@ogf.org For discussion on next WG call. Section 13.11.1. of the DFDL 1.0 spec defines the formatting symbols that can be used for calendar patterns. In addition to the supported ICU symbols, it also permits some extra symbols (I and T) that are used as a shorthand for ISO8601 format date/times. The following is quoted from the spec. Currently Symbol Meaning Presentation Example I ISO8601 Date/Time (Text) 2006-10-07T12:06:56.568+01:00 IU ISO8601 Date/Time (Text) 2006-10-07T12:06:56.568Z with output "Z" if the time zone is +00:00) T ISO8601 Time (Text) 12:06:56.568+01:00 (up to HH:mm:ss.SSSZZZ) TU ISO8601 Time (Text) 12:06:56.568Z (similar to T, but a time zone of +00:00 is replaced with 'Z') The 'I' and 'T' pattern characters should be used on their own to format dates and times which match the following subset of the ISO8601 standard. · The restricted profile as proposed by the W3C at http://www.w3.org/TR/NOTE-datetime · Truncated representations of calendar dates, as specified in section 5.2.1.3 of ISO8601:2000 o Basic format (subsections c, e, and f) o Extended format (subsections a, b, and d) An analysis shows that this definition of I and T is both incomplete and overly complex. The restricted W3C profile only defines the format for date/time and date-only, there is no time-only format The restricted W3C profile supports 6 'granularities' and states that referencing standards must say which they support The restricted W3C profile states that referencing standards must be explicit as to the number of fractional seconds supported The support for truncated representations of calendar dates was added to support xs:gYear, xs:gYearMonth, etc, which are not supported in 1.0 It does not say what the canonical output 'granularity' is. Proposal Here is what is proposed to correct this. Note the T symbol is dropped. It was introduced to allow xs:dateTime to expect just a time, but that is not necessary (it was copied from IBM MRM). I've stated any alternatives that we can consider at the end. Symbol Meaning Presentation Example I ISO8601 Date/Time (Text) 2006-10-07T12:06:56.568+01:00 IU ISO8601 Date/Time (Text) 2006-10-07T12:06:56.568Z with output "Z" if the time zone is +00:00) The 'I' symbol must not be used with any other symbol other than the 'escape for text' symbol. It represents calendar formats that match those defined in the restricted profile of the ISO8601 standard proposed by the W3C at http://www.w3.org/TR/NOTE-datetime.The formats are referred to as 'granularities'. xs:dateTime. When parsing, the data must match one of the granularities. When unparsing, the fullest granularity is used. xs:date. When parsing, the data must match one of the date-only granularities. When unparsing, the fullest date-only granularity is used. 'IU' is permitted for xs:date but the 'U' is effectively ignored as there is no time zone in the date-only granularities. xs:time. When parsing, the data must match only the time components of one of the granularities that contains time components. When unparsing, the time components of the fullest granularity are used. The literal 'T' character is not expected in the data when parsing and is not output when unparsing. The number of fractional second digits supported is implementation dependent but must be at least one. For a granularity that omits components, when parsing the values for the omitted components are supplied from the Unix epoch 1970-01-01T00:00:00.000 . Alternatives: As above but don't support the first two granularities ('Year', 'Year and month') on the grounds that they are really matching xs:gYear and xs:gYearMonth. Regards Steve Hanson Architect, Data Format Description Language (DFDL) Co-Chair, OGF DFDL Working Group IBM SWG, Hursley, UK smh@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 -- 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