FpML Issues Tracker
closed
Minor
Always
Validation Rules
Admin
mgratacos
Summary
This issue was resolved with the outcome that, as of the last two published drafts, all dates in the FpML examples now carry an explicit timezone offset expressed as "-00:00". If we insist that all samples should include the timezone, then we should use the canonical 'Z' form (e.g. 2007-08-15Z), which has the merit of introducing less visual clutter. However, use of the timezone is *not* a recommendation of the architecture, just documented as a solution where disambiguation is necessary. I endorse Andrew P's suggestion that we should produce a few samples to illustrate correct and consistent usage - I don't think a global change was indicated.
Notes:
mgratacos
08/16/07 9:23 pm
Harry,
In your opinion, which examples should include offsets and which not? How do we make that distinction?
I think that we are in the safe side if we include the offsets. Otherwise, it needs to be very clear why we have some examples with offsets and without offsets.
Thanks,
Marc
matthew
09/06/07 2:02 pm
The FpML Manual says:
”
4.6.1 Evaluation of Dates
The evaluation of dates in the validation rules is not trivial. The optionality of including time offsets in date datatypes makes comparisons between dates more difficult since sometimes the result is indeterminate as any ISO8601 date is +/- 18 hours of timezone, and +/- 24 hours of day.
The Validation Working Group recommends the use of the XPath 2.0 date/time comparison rules which defines a definitive true / false value even for indeterminate calculations.
The Architecture Specification also suggests that time offsets appear on all date/time values used in FpML documents.
”
The last sentence needs fixing, because the Architecture specification doesn’t say this.
I suggest it is replaced with:
“The Validation Working Group recommends that time offsets appear on all date/time values used in FpML documents.”
matthew
09/06/07 8:53 pm
Moved to VWG after AWG discussion. Daniel Dui to present as the joint member.
h_mcallister
09/10/07 10:54 am
(1) XPath 2.0 resolves indeterminate date/time comparisons by invoking an implementation dependent “implicit timezone” – in other words, using XPath 2.0 comparisons doesn’t solve the problem on its own.
(2) The validation rules operate on intra-document values, by definition. Indeterminate date/time comparisons will not arise, provided document authors observe the existing Architecture recommendation that timezone should be applied (or omitted) consistently throughout the document. The VWG is not compelled to recommend any particular policy on the use of timezones, other than that a consistent style is applied on elements subject to comparison by the validation rules.
(3) Let’s use consistent terminology: “[time] offset” is an informal term which does not appear in the W3C Recommendations on XML Schema or XPath. The formal term is “timezone”.
(4) “any ISO8601 date is +/- 18 hours of timezone, and +/- 24 hours of day”.
(a) XML Schema dateTimes accomodate +/- 14 hours of timezone (not 18). Timezones in current use span +12/-13 hours (according to the Recommendation).
(b) How should we construe “-24 hours of day”?
matthew
09/10/07 12:21 pm
(A1) Agreed with Harry. For reference the definition is: http://www.w3.org/TR/xpath20/#dt-timezone “[Definition: Implicit timezone. This is the timezone to be used when a date, time, or dateTime value that does not have a timezone is used in a comparison or arithmetic operation. The implicit timezone is an implementation-defined value of type xs:dayTimeDuration. See [XML Schema] for the range of legal values of a timezone.]”
(A2) If it could be made a firm rule that the timzeone offset must be applied or not consistently, then this problem would disappear for the VWG because it only looks at intrad-document values. Harry – would you agree on making it a firm rule so that this was now a non-issue? For cross-document comparisons such as in business process this would be an issue, as we don’t have any yet this is a bridge to cross when we come to it.
(A3) The W3C’s formal term has changed and the specifications do not. Should we be consistent with the W3C historical terminology in the specification or always stick to the current terminology? I have no problem with either consistency.
http://www.w3.org/TR/2005/NOTE-timezone-20051013/#d2e226
“[XML Schema] follows the [ISO 8601] standard for its lexical representation. Date and time values in ISO 8601 are field-based using the definitions above and can indicate (or omit) the zone offset from UTC. A zone offset is not the same thing as a time zone, and the difference can be important. XML Schema only supports zone offset, but, confusingly, calls it time zone, see for example section 3.2.8.1, lexical representation in [XML Schema].”
(A4) Transposing 18 with 14 was an error. I was simply unclear, I meant it is within a day that the +/-14 hours applies.
mgratacos
09/25/07 1:42 pm
Validation Working Group 2007-09-25: Agreed to add a rule (not warning) for the consistent use of date offsets. We will keep samples of both, with or without offsets.
mgratacos
10/22/07 4:10 pm
Date offsets should be present in all dates or none of them within a message.
Should we list exceptions to this rule?
* Should message header be included in this rule?
* hourMinuteTime doesn’t use offsets…it is implied by the business center. This would break the rule (exercise components)
matthewdr
03/11/08 10:51 am
The next step is for Marc’s questions to be discussed at the VWG.
iyermakova
05/20/08 2:05 pm
ValWG 2008-05-20: agreement to change the examples and update the rule to match.
mgratacos
05/23/08 7:53 am
Rule to check consistency of offsets needs to be defined.
matthewdr
12/12/08 12:39 pm
I wrote out both rules agreed by the VWG in Precise form, English form, and with a comment. The new rules are:
shared-26 (Mandatory)
Precise Context: document()
Precise Rule: count(distinct-values(//((element(*, xs:date)|attribute(*, xs:date))/timezone-from-date(.),(element(*, xs:dateTime)|attribute(*, xs:dateTime))/timezone-from-dateTime(.)))) eq 1
English Context: the whole document
English Rules: all timezones must be the same. +00:00, -00:00, and Z are considered equivalent.
Comment: This rule ensures that date and datetime comparisons behave as expected because they’re expressed in the same timezone. NB That the XSD specification uses the term “timezone”, but that they are not really timezones as they are fixed durations to represent time offsets. Subsequent to publishing XSD the W3C changed its position to clarify this: http://www.w3.org/TR/2005/NOTE-timezone-20051013/#d2e226.
shared-27 (Mandatory)
Precise Context: document()
Precise Rule: count(//((element(*, xs:date)|attribute(*, xs:date))/timezone-from-date(.),(element(*, xs:dateTime)|attribute(*, xs:dateTime))/timezone-from-dateTime(.))) eq count(//(element(*, xs:date)|attribute(*, xs:date),element(*, xs:dateTime)|attribute(*, xs:dateTime)))
English Context: the whole document
English Rules: all dates and times must have a timezone or none of them must.
Comment: This rule requires all dates and datetimes to have timezones or none of them must. This is to ensure the comparison of these fields behaves as expected. NB That the XSD specification uses the term “timezone”, but that they are not really timezones as they are fixed durations to represent time offsets. Subsequent to publishing XSD the W3C changed its position to clarify this: http://www.w3.org/TR/2005/NOTE-timezone-20051013/#d2e226.
matthewdr
12/16/08 2:14 pm
Agreed at VWG today to implement as proposed.
lyteck
12/16/08 8:06 pm
will implement as shared-27 and shared-28 (because we just used shared-26 for issue 732)
lyteck
12/16/08 8:25 pm
implemented shared-27, shared-28 as proposed (except for the “English” context which is part of implementing issue 866. shared context left as “Document (Complex Type)”)