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] Implicit conversion and medical data

> Well, but so far as I can tell there is no prohibition in place in 
> OpenDocument to prevent someone from constructing an application that 
> behaves as you describe even though it is using OpenDocument format. Yes?

True.  Though there are cases where, in fact, this is _desirable_, which
is why it's the default in Excel.

> I think a warning, whether in the standard or not is another issue, 
> would be a good idea. I would assume data corruption would be something 
> of interest to the soon to be formed implementation/interoperability TC.

Yes, though it basically boils down to "When saving or loading files in formats
other than OpenDocument, we recommend that you not corrupt the data".
We can't really _mandate_ that, but a warning might make sense.

Something like this in the spreadsheet material, perhaps:

Note: When loading tables from simple text formats (e.g., CSV formats) that
are not OpenDocument, we recommend providing a method to indicate
that certain columns or all columns are text files.  If the application always
'guesses' the format to determine which fields are numbers, dates, and so on,
it may silently corrupt data, which would produce
corrupted results when later saved in OpenDocument.
This is particularly a concern for biomedical data, since some data
may look exactly like number or date values yet should be interpreted as text.

Although it's not _really_ an OpenDocument issue, it will affect the
accuracy of data saved in OpenDocument, so I guess that's an argument
for noting it in the spec.

--- David A. Wheeler

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