RE: [oic] profiles: ODF 1.2 or 1.1

["Dennis E. Hamilton" <dennis.hamilton@acm.org>]

I think it is prudent to continue our focus on ODF 1.1 at this point:

 * It is a stable, existing specification with implementations that can be
investigated with regard to conformance
 * For the most part, everything we have in 1.1 is preserved in ODF 1.2
(including the normative language or lack thereof).
 * The ODF 1.2 cd01 is just for Part 1 of what will be a three part
specification, and it is not clear what sort of work will be done between
now and a cd that will be offered for public comment.

Depending on how quickly we are able to move, I think that the kind of
critical attention that our focus on conformance and interoperability
provides will be useful feedback to ODF 1.2 and they can look over our
shoulders about that (plus we have a significant membership overlap).  We
don't need to be sending requests to ODF 1.2 as activity of the OIC TC. 

Finally, with regard to advocacy for provisions to the ODF 1.2 specification
itself, I think that is too close to an inappropriate collision of our
charter and that of the ODF TC. 

Now that there is a Part 1 cd01 considered stable enough, organizationally,
for ongoing review and refinement, those of us with an interest in
provisions of that specification should address our comments to the ODF TC
List (if we are members) or to the office-comment list (if we are not).  I
believe that the ODF TC will welcome such input, especially around
blemishes, omissions, and possible disconnects/regressions with respect to
provisions of 1.1 and IS 26300.  This will be very valuable in their
assessment of public-review readiness and in achieving a positive public
review when the time comes.

If we come up with test assertions and test cases, along with identification
of gaps in the normative language of 1.1, I suspect that the ODF TC could
consider those in a version of ODF.  It is not clear to me that the ODF TC
would hold up 1.2 for such a revamping.  Even so, what we come up with can
probably be reapplied to ODF 1.2 without too much difficulty when
implementations show up; what we do with regard to 1.1 is probably valuable
to ODF 1.2 implementers as well as ODF 1.1 sustainers. 

I share Rob Weir's thoughts
(http://lists.oasis-open.org/archives/oic/200902/msg00043.html) that working
on test cases is the most valuable activity that we can provide, with that
work being extremely reusable from 1.1 onward if targeted on those areas
which are the hot spots for conformance and acceptable interoperability.  I
think we lack the knowledge, at this time, to be proposing profiles of ODF
with respect to any specification.  I can't imagine any early one that
wouldn't fit ODF 1.1 also (except for spreadsheets, perhaps).  Also, I don't
think we should have a profile that we don't have a means to assess for.
The tests and understanding of the state of interoperability come first and
must inform our profiles.

 - Dennis

PS: The OpenFormula work in the planned Part 2 is brand new specification,
and it would be worthwhile to address that as soon as there is a committee
specification, perhaps even earlier.  Currently, OpenFormula is specified as
a module that can be used independently, with only a few prerequisites on
its use in table:formula values in ODF Documents.  Since that is the largest
new part of ODF 1.2, I would think that is the first thing to apply our
analysis to when we turn to 1.2 concerns.  For other added chunks, such as
digital signatures and RDF metadata, they can be taken on as incremental to
the 1.1 work when they rise above the cut of important areas to address for
conformance and interoperability.

-----Original Message-----
From: Hanssens Bart [mailto:Bart.Hanssens@fedict.be] 
http://lists.oasis-open.org/archives/oic/200902/msg00041.html
Sent: Wednesday, February 18, 2009 00:59
To: OIC TC List
Subject: [oic] profiles: ODF 1.2 or 1.1

Dear OIC members,


Now the first ODF 1.2 community draft became available, I'd like your
opinion on the ODF version we should target when advising the ODF TC
regarding profiles.

[ ... ]