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

[Hanssens Bart <Bart.Hanssens@fedict.be>]

*cough* we can create profiles in the OIC TC (that wouldn't be on
par as a standard, but it may serve our purposes for a practical
point of view, probably not for legal matters)

This, of course, requires a non-trivial amount of resources, which
are probably not going to be available before 1.2 is finished and
a few product launches are done (hopefully I'm wrong on this
point)

Bart
________________________________________
From: robert_weir@us.ibm.com [robert_weir@us.ibm.com]
Sent: Saturday, October 31, 2009 1:31 PM
To: opendocument-users
Subject: Re: [opendocument-users] Adding tables to ODP files

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

---------------------------------------------------------------------
To unsubscribe, e-mail: opendocument-users-unsubscribe@lists.oasis-open.org
For additional commands, e-mail: opendocument-users-help@lists.oasis-open.org