OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

office-comment message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: Re: [office-comment] Re: ODF 1.2 CD03 (all versions) 17.3.13 (dateOrDateTime)


Just for future reference, note that dateOrDateTime is defined as:

<define name="dateOrDateTime">
        <data type="date"/>
        <data type="dateTime"/>

Considering that we then define date as date and dataTime as dataTime in 
the schema and we reference xmlschema-2 in the prose, I suspect the 
answer is that either an xmlschema-2 data value or an xmlschema-2 
dateTime value is acceptable.

The term "essentially" occurs three times in the text and I will work on 
excising that before the next posted version. Not a useful term in a 


Hope you are having a great day!


Jesper Lund Stocholm wrote:
> see below,
> 2009/10/8 Jesper Lund Stocholm <4a4553504552@gmail.com>:
>> Description:
>> Section 17.3.13 (dateOrDateTime) has the following text:
>> "A dateOrDateTime value is essentially an [xmlschema-2] date and time
>> value with an optional time component. In other words, it may contain
>> either a date, or a date and time value."
>> Problem:
>> It is unclear to me what "essentially" means. Does the value sometimes
>> not contain an xmlschema-2 date and time value?
>> Proposed solution:
>> Make it clear that either:
>> 1) a dateOrTime value is defined (and must conform to) as specified in
>> http://www.w3.org/TR/2004/REC-xmlschema-2-20041028/#dateTime
>> (basically the reference that is already used)
>> 2) add descriptive text to the specification with examples of when
>> "essentially" applies and when "essentially" does not apply.
>> I would encourage ODF TC to go with "option 1". It would enable
>> maximum reuse of existing libraries conforming to "xsd:datetime".
> A further comment,
> As this data type is used in <table:table-cell> attribute
> office:date-value, the ambiguity of the specification bubbles all the
> way up to calculations in spreadsheets. It is imo extremely important
> to have an unambiguous specification of the date format in ODF -
> otherwise calculations on dates in spreadsheets will rely on
> (error-prone) asumptions while parsing text - possibly leading to
> faulty calculations.

Patrick Durusau
Chair, V1 - US TAG to JTC 1/SC 34
Convener, JTC 1/SC 34/WG 3 (Topic Maps)
Editor, OpenDocument Format TC (OASIS), Project Editor ISO/IEC 26300
Co-Editor, ISO/IEC 13250-1, 13250-5 (Topic Maps) 

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]