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