[DFDL-WG] Issue 162: Re: Proposed spec errata for calendarPattern I and T symbols

[Mike Beckerle]

I reviewed this. The proposal looks fine as-is.  I don't think the lack of
gYear and gYearMonth types should affect the functionality offered. We left
those out not because people don't want formats like that, but because we
can handle those formats even without the additional types.

Do we need to clarify that the longest granularity is tried first, and this
is greedy parsing? If the data matches one of the granularities there will
be no backtracking to try others.



> *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.*<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* <http://www.ogf.org/dfdl/>
> IBM SWG, Hursley, UK*
> **smh at uk.ibm.com* <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
>



-- 
Mike Beckerle | OGF DFDL WG Co-Chair
Tel:  781-330-0412
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.ogf.org/pipermail/dfdl-wg/attachments/20120117/c0d70054/attachment.html>