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


Help: OASIS Mailing Lists Help | MarkMail Help

opendocument-users message

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

Subject: Re: [opendocument-users] Guidance for using cells in tables (ODFSpreadsheets)

I just thought of a legitimate use case.  A cell with a formula =NOW().

The table:formula attribute and the value stored in the cell would would 
quickly go out of alignment, since one is hard-coded in the XML and one 
has a value that reflects the current time.  Both values are correct and 
have a use according to the type of application that is processing it.  A 
full spreadsheet application will typically recalculate the sheet upon 
loading it, updating the cell contents accordingly.  But a lightweight 
viewer, a search engine indexer, or the AODL toolkit that lacks a 
calculation engine will generally use the stored values directly, in which 
case the values are only as fresh as the last time the document was 
written.  Either one is a legitimate use.  And although there are edge 
cases, the volatile functions like NOW and RAND, your best bet is to 
ensure that the value and the contents of the cell differ only in format, 
not in meaning. 

Of course not every application will have a full calculation engine.  Take 
toolkits for example.  So in that case I'd recommend just leaving the 
contents empty if you are not able to set something reasonable.  A full 
spreadsheet application will recalc the sheet upon opening and set the 
contents at that point.  Of course, you'll be out of luck with search 
indexing, lightweight viewing or other applications that don't have a 
calculation engine.  But those are the trade-offs.



Jesper Lund Stocholm <4a4553504552@gmail.com> wrote on 10/08/2009 06:51:58 

> As I have been adding support to the .Net-library AODL for cells with
> dates in spreadsheets, I have had some trouble understanding what the
> intended usage of <table:table-cell> and its attributes are.
> In the specific case, my implementation creates the following markup
> for a cell in a spreadsheet with a date in it:
> <table:table-cell office:value-type="date"
> office:date-value="2009-10-08T09:45:00" />
> However, the <table:table-cell>-element also allows storing paragraphs
> in them, so an equally valid markup would be
> <table:table-cell office:value-type="date"
> office:date-value="2009-10-08T09:45:00" >
>   <text:p>08-10-2009 9:45</text:p>
> </table:table-cell>
> (note that the date itself is stored in UTC-format whereas the
> paragraph contains the date formatted for Danish locale/culture)
> This markup led me to create this markup, which is valid (I presume)
> but doesn't make a lot of sense.
> <table:table-cell office:value-type="date"
> office:date-value="2009-10-08T09:45:00" >
>   <text:p>No date, just text</text:p>
> </table:table-cell>
> Now, I have been trying to find some guidance in ODF spec to the
> intended application behaviour - but I have found nothing on the
> subject. For instance, should the <text:p>-element be ingored, if the
> cell is of type "date"? Should (a conflicting) value-type of the cell
> be ignored, if the cell has a paragraph in it?
> (I assume this ambiguity applies to all conflicts between cell value
> type and specific content in the cell)
> So my question is really, is the behaviour in this scenario purely
> application defined - or is there some guidance in ODF spec, that I
> have missed?
> -- 
> Jesper Lund Stocholm
> www.idippedut.dk
> SC34/WG4 http://www.itscj.ipsj.or.jp/sc34/wg4/
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: 
> For additional commands, e-mail: 

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