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

 


Help: OASIS Mailing Lists Help | MarkMail Help

office message

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


Subject: Re: [office] Data Grid Size element proposal


Reading between the lines in the discussion so far, it sounds like the key 
issue is that formulas in spreadsheet table may make assumptions about the 
capabilities (namely max grid size)of the application containing that 
table.  Under a rather bizarre set of circumstances, a spreadsheet can be 
contrived that could depend on such knowledge.  But this is just a 
specific case of a more general issue.  Look at spreadsheet formulas, and 
how different implementations implement a different subset of functions. 
That kind of mismatch is far more likely to occur than any problem with 
different grid sizes.

So, to state the general problem, ODF features are optional, meaning 
conformance applications are not required to implement any specific 
functions (beyond a few basic ones related to processing packages and 
foreign elements and attributes).  So any given document may or may not be 
fully understandable and fully processable by any given implementation.

One solution would be for a document to declare what features it requires 
from an applications, the assumptions it makes about capabilities.  For 
example, a document might say it requires nested tables, footnotes, and 
support for PNG images.  This could be put in a header, perhaps even in 
the manifest, and would help an application to decide whether or not it 
was capable of handling the document.

Another solution starts from noting that the use of a given element in an 
ODF document is already an indication of a dependency.  So in most cases, 
an upfront declaration of dependencies is likely to be redundant.  You 
would get the same results by parsing the document.  But there may be 
exceptions.  Some things are easier to parse out than others.  And if the 
desire is to prevent loading or to give a warning message before loading, 
some things, like what ODF version you are using, what fonts you require, 
etc., need to be very easily accessible.

So, it might be worth considering that more general topic -- how should 
ODF documents indicate their assumptions and requirements on the 
implementation, whether for specific functions and features, or in terms 
of limits such as grid size.  Or do we in general require implementations 
to determine this deductively, as they parse the document.

Regards,

-Rob


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