[DFDL-WG] Proposed spec errata for calendarPattern I and T symbols

Mon Jan 16 05:00:50 EST 2012

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 at uk.ibm.com
Tel. 01962-816742 
Internal tel. 246742

From:   Steve Hanson/UK/IBM at IBMGB
To:     dfdl-wg at 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 at 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 at 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 at 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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.ogf.org/pipermail/dfdl-wg/attachments/20120116/748110a0/attachment.html>