Re: [opendocument-users] Adding tables to ODP files

[robert_weir@us.ibm.com]

marbux <marbux@gmail.com> wrote on 10/31/2009 12:53:09 AM:

> 
> On Fri, Oct 30, 2009 at 9:05 PM, Dennis E. Hamilton
> <dennis.hamilton@acm.org> wrote:
> 
> > In that respect, there is a Non-Normtive Appendix describing Core 
Features
> > Sets.  That Appendix indicates that the Basic Table Model and the 
Advanced
> > Table Model are not considered core features of Presentation 
documents.
> > This Appendix appears in the ODF 1.0, IS 26300, and ODF 1.1 
specifications.
> >
> > The most likely difference in ODF 1.2 in this regard is the potential
> > omission of that Appendix.
> 
> 
> It's ironic that the particular Appendix may be on the path to
> oblivion. That appendix is as close as the ODF TC ever came to a
> profile for interoperability of ODF implementations. I.e., a profile
> as described in the TC Charter, for:
> 
> "b. establishing a set of 'core' elements and attributes *to be*
> supported by *all* implementations,"
> 
> (Scope section; emphasis added.) /1/
> 

That was the thought, that this Appendix would be beefed up and made into 
a profile standard or set of such standards. Obviously, getting consensus 
around what exactly constitutes the core functionality of a presentation 
will require additional substantial discussion.  It is something worth 
doing, I think.  But what was in the appendix was not accurate for any 
implementation, not even OpenOffice.  So it was removed.

In the ODF Toolkit Union we need to think about what a profile like that 
would mean for ODFDOM.  As written today, ODFDOM allows everything 
supported by the ODF 1.2 schema, regardless of whether an implementation 
actually can render that particular combination of features.  So the 
programmer needs to know the limitations of whatever app they are 
targeting.  It would certainly be nice to have a mode where you set what 
your target app is, or pick a profile to maximize interoperability, and 
have the ODFDOM library adapt, but I'm not sure how that would work.  You 
can certainly code it so a runtime exception is called whenever a 
non-supported function is called.  But that sucks, because it will not 
find all bugs unless you have 100% path coverage in your test cases.  What 
you want is for any violations to be statically testable.  So that in 
practice means agreeing on a schema of specific subset of ODF that is 
applicable for a given use.

-Rob