OASIS Open Document Format for Office Applications (OpenDocument) TC

Back to discussions
Expand all | Collapse all

Data Grid Size element proposal

  • 1.  Data Grid Size element proposal

    Posted 11-19-2008 00:02 
    










    


    Dear TC members,
    


    


    I have created a proposal on a new Table Grid Size element: http://wiki.oasis-open.org/office/Table_Grid_Size_element
    


    


    Regards,
    


    Doug
    


    


    Doug Mahugh | Senior Program Manager | Office Interoperability |
425-707-1182 | blogs.msdn.com/dmahugh


  • 2.  Re: [office] Data Grid Size element proposal

    Posted 11-19-2008 17:42 
    Why not just have a way to specify formatting for an entire row?

I'm not comfortable with heuristically determining that an attribute
applied to all the columns (or rows) in one app and magically
extending it to all columns (or rows) in another app. I think it's a
really hacky solution.

wt

On Tue, Nov 18, 2008 at 16:01, Doug Mahugh


  • 3.  Re: [office] Data Grid Size element proposal

    Posted 11-20-2008 06:13 
      
    
    
  
  
    
    
      Hi Warren,    

          
    
    
      I'm comfortable with adding a *new* way of adding attributes to cells and rows for backward compatibility reasons.    
    
    
    
      I'd rather have a backward compatible solution, such that ODF 1.0/1.1 and readers get the most information -- they understand --- out of the document.    

          
    
    
      When adding a formatting for an entire row ODF 1.0/1.1 readers will ignore its and all the formatting gets lost. Do we really want this?    

          
    
    
      Regards,    

          
    
    
      ~Florian    
    
    


      >>> Warren Turkal <turkal@google.com> 11/19/2008 6:42 PM >>>
    Why not just have a way to specify formatting for an entire row?

    I'm not comfortable with heuristically determining that an attribute
    applied to all the columns (or rows) in one app and magically
    extending it to all columns (or rows) in another app. I think it's a
    really hacky solution.

    wt

    On Tue, Nov 18, 2008 at 16:01, Doug Mahugh <Doug.Mahugh@microsoft.com> wrote:
    > Dear TC members,
    >
    >
    >
    > I have created a proposal on a new Table Grid Size element:
    > http://wiki.oasis-open.org/office/Table_Grid_Size_element
    >
    >
    >
    > Regards,
    >
    > Doug
    >
    >
    >
    > Doug Mahugh | Senior Program Manager | Office Interoperability |
    > 425-707-1182 | blogs.msdn.com/dmahugh
    >
    >

    ---------------------------------------------------------------------
    To unsubscribe from this mail list, you must leave the OASIS TC that
    generates this mail.  Follow this link to all your TCs in OASIS at:
    https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php


  • 4.  RE: [office] Data Grid Size element proposal

    Posted 11-20-2008 16:51 
    












    


    Warren,
    


    


    By heuristics, are you
referring to client code like this?
    


       if
(number-columns-repeated == col-max) then 
    


          
{extend or shrink formatting to current client's maximum columns}
    


    


    I’d call that
deterministic myself, but what would you prefer?  
    


    As Florian said, something
like table:number-columns-repeated="MAX_COLS" would not be backwards
compatible with existing ODF 1.1 readers.
    


    I’m open to anything
that addresses the issue, preferably without introducing a breaking change.
    


    


    Regards,
    


    Doug
    


    


    


    From: Florian Reuter
[mailto:freuter@novell.com]
    
Sent: Wednesday, November 19, 2008 10:13 PM
    
To: Warren Turkal
    
Cc: office@lists.oasis-open.org
    
Subject: Re: [office] Data Grid Size element proposal
    


    


    


    


    Hi Warren,

    


    


    I'm comfortable
with adding a *new* way of adding attributes to cells and rows for backward
compatibility reasons. 
    


    I'd rather have
a backward compatible solution, such that ODF 1.0/1.1 and readers get the most
information -- they understand --- out of the document. 
    


    


    When adding a
formatting for an entire row ODF 1.0/1.1 readers will ignore its and all the
formatting gets lost. Do we really want this? 
    


    


    Regards, 
    


    


    ~Florian 
    




    
>>> Warren Turkal <turkal@google.com> 11/19/2008 6:42 PM
>>>
    
Why not just have a way to specify formatting for an entire row?

    
I'm not comfortable with heuristically determining that an attribute
    
applied to all the columns (or rows) in one app and magically
    
extending it to all columns (or rows) in another app. I think it's a
    
really hacky solution.

    
wt

    
On Tue, Nov 18, 2008 at 16:01, Doug Mahugh <Doug.Mahugh@microsoft.com>
wrote:
    
> Dear TC members,
    
>
    
>
    
>
    
> I have created a proposal on a new Table Grid Size element:
    
> http://wiki.oasis-open.org/office/Table_Grid_Size_element
    
>
    
>
    
>
    
> Regards,
    
>
    
> Doug
    
>
    
>
    
>
    
> Doug Mahugh | Senior Program Manager | Office
Interoperability |
    
> 425-707-1182 | blogs.msdn.com/dmahugh
    
>
    
>

    
---------------------------------------------------------------------
    
To unsubscribe from this mail list, you must leave the OASIS TC that
    
generates this mail.  Follow this link to all your TCs in OASIS at:
    
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php


  • 5.  RE: [office] Data Grid Size element proposal

    Posted 11-20-2008 17:34 
    On Thu, 2008-11-20 at 08:51 -0800, Doug Mahugh wrote:
> Warren,
> 
>  
> 
> By heuristics, are you referring to client code like this?
> 
>    if (number-columns-repeated == col-max) then 
> 
>        {extend or shrink formatting to current client's maximum
> columns}
> 
>  
> 
> I’d call that deterministic myself, but what would you prefer?  
> 
> As Florian said, something like
> table:number-columns-repeated="MAX_COLS" would not be backwards
> compatible with existing ODF 1.1 readers.
> 
> I’m open to anything that addresses the issue, preferably without
> introducing a breaking change.
> 

I am wondering whether something like table:grid-size doesn't also have
repercussions on evaluation of formulae. Imagine a formula that refers
to a cell location outside the current grid. What happens is this
formula suddenly finds itself in a larger grid?

Andreas


  • 6.  Re: [office] Data Grid Size element proposal

    Posted 11-21-2008 17:03 
    Hi,

On Thursday, 2008-11-20 10:34:17 -0700, Andreas J. Guelzow wrote:

> I am wondering whether something like table:grid-size doesn't also have
> repercussions on evaluation of formulae. Imagine a formula that refers
> to a cell location outside the current grid. What happens is this
> formula suddenly finds itself in a larger grid?

Might evaluate to something (maybe something wrong) then, where before
it should had resulted in an error. Unless you artificially limit the
sheet size as well.

There's more to it though. For named expressions (ranges or formulae)
there is the strange and awkward behavior required for interoperability
that for relative references the references _wrap_ around the sheet if
the position of the formula cell moves towards an edge. When loaded in
another grid size, the wrapped position will be different, thus the
formula result may as well.

We should at least give some recommendations what to do in such cases,
better would be clear definitions.

  Eike

-- 
 OpenOffice.org / StarOffice Calc core developer and i18n transpositionizer.
 SunSign   0x87F8D412 : 2F58 5236 DB02 F335 8304  7D6C 65C9 F9B5 87F8 D412
 OpenOffice.org Engineering at Sun: http://blogs.sun.com/GullFOSS


  • 7.  RE: [office] Data Grid Size element proposal

    Posted 11-21-2008 23:16 
    Warren, your suggestion looked to me like a good way to address the specific problem of row/column formatting that I had described in the proposal.

An optional grid-size element may also be useful in other circumstances, including scenarios we haven't considered.  I'd like to revise the proposal to include the grid-size element as well as attributes for formatting an entire row or entire column.  Does anybody see any problem with that?

Andreas and Eike, regarding formula references, I'm not sure what the best solution would be to the scenarios you have described.  The grid-size element would give consumers enough information to know whether the spreadsheet was created on an implementation with a different grid size, so that they can do whatever they feel is appropriate.  Perhaps we could look at some recommendations as Eike suggested, based on use of this element.

Regards,
Doug



    
                                                
    
					
                                                    

        
                                                
				
    
                                                
    
                                                    
                                                        
                                                        Original Message


  • 8.  Re: [office] Data Grid Size element proposal

    Posted 11-21-2008 23:34 
    Can you please describe a situation that still requires the explicit
grid-size elements? I'm having a hard time coming up with a use case
for them if there is a way to just apply a style to a whole row (or
column).

wt

On Fri, Nov 21, 2008 at 15:15, Doug Mahugh


  • 9.  RE: [office] Data Grid Size element proposal

    Posted 11-21-2008 23:48 
    Eike's example provides a good description of such a situation:

> There's more to it though. For named expressions (ranges or formulae) there is the strange and awkward behavior required for interoperability that for relative references the references _wrap_ around the sheet if the position of the formula cell moves towards an edge. When loaded in another grid size, the wrapped position will be different, thus the formula result may as well.

Given these sorts of ramifications of variations in grid size, the presence of an (optional) grid-size element would be useful.  Otherwise, how would a consumer know that the spreadsheet is being loaded in "another grid size"?

I suppose we could come up with an alternative specifically targeted at the relative-reference issue, as you've suggested for the formatting issue, but the underlying issue in both cases is that the grid size has changed.  In the long run I think it may be simpler to explicitly store grid-size information than to create a separate custom solution for each grid-size issue that arises.

Do you feel that the addition of this optional element would cause any problems?

- Doug



    
                                                
    
					
                                                    

        
                                                
				
    
                                                
    
                                                    
                                                        
                                                        Original Message


  • 10.  RE: [office] Data Grid Size element proposal

    Posted 11-22-2008 01:44 
    On Fri, 2008-11-21 at 15:47 -0800, Doug Mahugh wrote:
> Do you feel that the addition of this optional element would cause any problems?

It occurred to me that some applications may not want to have a maximum
grid size at all. (At least it is a frequent request by gnumeric users.)
So shouldn't we already provide for the possibility that the maximum
gridsize is in fact infinite?

Andreas

-- 
"Liberty consists less in acting according to
one's own pleasure, than in not being subject 
to the will and pleasure of other people. It 
consists also in our not subjecting the wills 
of other people to our own."  Rousseau


Prof. Dr. Andreas J. Guelzow
Dept. of Mathematical & Computing Sciences
Concordia University College of Alberta


  • 11.  Re: [office] Data Grid Size element proposal

    Posted 11-22-2008 02:10 
    I don't really see the problem with an error being caused by a
reference to a cell outside the user agent's range going away when
opening the doc in a user agent with a greater number of cells. I
could only see that mattering if you rely on the error for some logic
in your spreadsheet. That just seems like a bad idea.

But maybe I am being dense here. If so, could you please give a
concrete and real world example?

wt

On Fri, Nov 21, 2008 at 15:47, Doug Mahugh


  • 12.  Re: [office] Data Grid Size element proposal

    Posted 11-22-2008 02:53 
    On Fri, 2008-11-21 at 18:09 -0800, Warren Turkal wrote:
> I don't really see the problem with an error being caused by a
> reference to a cell outside the user agent's range going away when
> opening the doc in a user agent with a greater number of cells. I
> could only see that mattering if you rely on the error for some logic
> in your spreadsheet. That just seems like a bad idea.

While I agree that it is a bad idea to depend on it, over my years as
developer of Gnumeric I have seen lots of spreadsheets were users have
used really strange constructions and even the type of error returned by
functions mattered. If you are worried about interoperability (as we
Gnumeric developers have been with respect to Excel then you have to
cover even for the strangest situations.
> 
> But maybe I am being dense here. If so, could you please give a
> concrete and real world example?

Since I personally wouldn't do that I have to have a look around for
one.

Andreas
> 
> wt
> 
> On Fri, Nov 21, 2008 at 15:47, Doug Mahugh


  • 13.  Re: [office] Data Grid Size element proposal

    Posted 11-22-2008 04:31 
    On Fri, 2008-11-21 at 18:09 -0800, Warren Turkal wrote:
> I don't really see the problem with an error being caused by a
> reference to a cell outside the user agent's range going away when
> opening the doc in a user agent with a greater number of cells. I
> could only see that mattering if you rely on the error for some logic
> in your spreadsheet. That just seems like a bad idea.
> 
> But maybe I am being dense here. If so, could you please give a
> concrete and real world example?

Let's see:
The following formula is from
http://theimmersivelife.blogspot.com/2008/08/tools-of-trade-google-apps-as.html
=ARRAYFORMULA(OFFSET(A1,INT(MAX(NOT(ISBLANK(C3:C200))*(COLUMNS($B1:
$IW1)*ROW(C3:C200)+COLUMN(C3:C200)))/COLUMNS($B1:
$IW1))-1.0,MOD(MAX(NOT(ISBLANK(C3:C200))*(COLUMNS($B1:
$IW1)*ROW(C3:C200)+COLUMN(C3:C200)))/COLUMNS($B1:$IW1),1.0)*COLUMNS($B1:
$IW1)-1.0))

This formula is invalid in Gnumeric with its default grid size but would
be valid with a larger gridsize. Suppose a program with a larger
gridsize saves this formula, it would be useful if gnumeric could easily
determine that the sheet comes from such a larger grid.

http://groups.google.com/group/How-to-Documents/browse_thread/thread/1f3ab6e086392bd4 seems to do some similar.

Moreover, the code in
http://www.excelforum.com/excel-programming/584805-run-time-error-1004-a.html
would not have shown that error in a gridsize larger than 256 columns.

Andreas

> wt
> 
> On Fri, Nov 21, 2008 at 15:47, Doug Mahugh


  • 14.  Re: [office] Data Grid Size element proposal

    Posted 11-24-2008 20:45 
    On Fri, Nov 21, 2008 at 20:30, Andreas J Guelzow


  • 15.  RE: [office] Data Grid Size element proposal

    Posted 11-24-2008 21:16 
    Warren, it's clear that you don't agree with the reasoning that has led several other implementers to conclude that a grid-size element would be useful, but you've not answered my question about what problems you feel the addition of this element would cause.  Do you have a specific argument against the proposal itself?

It seems to me that an optional element which multiple implementers find useful is worth considering as an addition, barring a specific reason that it would cause problems.

Thanks,
Doug


    
                                                
    
					
                                                    

        
                                                
				
    
                                                
    
                                                    
                                                        
                                                        Original Message


  • 16.  Re: [office] Data Grid Size element proposal

    Posted 11-24-2008 23:40 
    On Mon, Nov 24, 2008 at 13:16, Doug Mahugh


  • 17.  RE: [office] Data Grid Size element proposal

    Posted 11-24-2008 23:52 
    If the bar is based on the feature offering useful functionality, that bar has clearly been met.  I and my colleagues here at Microsoft would find this element useful for improving interoperability.  Eike pointed out a scenario where he would find it useful.  Andrew described multiple scenarios where he would find it useful.

I believe the bar you're using here is more accurately entitled "does Warren Turkal find this feature useful?"  That's something only you can decide, and you've clearly made up your mind.  Let's agree to disagree.

Meanwhile, we need to answer the question of whether this feature should be added.  I'll get it on the ODF 1.2 list, and we can vote on it in a future call.  No need to burn any more time at this point, I think all the relevant points have been made on both sides of this one.

Thanks,
Doug



    
                                                
    
					
                                                    

        
                                                
				
    
                                                
    
                                                    
                                                        
                                                        Original Message


  • 18.  Re: [office] Data Grid Size element proposal

    Posted 11-24-2008 21:59 
    You are referring to "an explicit maximum size". This makes it sounds
like the proposal is to fix a maximum size. It is really about
specifying which size was in use when the sheet was saved. 

Andreas



-- 
Andreas J. Guelzow


  • 19.  Re: [office] Data Grid Size element proposal