Re: [oiic-formation-discuss] (1)(d) A list of deliverables,with projected completion dates.

[Michael Brauer - Sun Germany - ham02 - Hamburg <Michael.Brauer@Sun.COM>]

Hi Rob,

robert_weir@us.ibm.com wrote:
> 
> Michael.Brauer@Sun.COM wrote on 06/13/2008 07:38:55 AM:
> 
>  > robert_weir@us.ibm.com wrote:
>  > >
>  > > Another piece I suggest we start working on:  "(1)(d) A list of
>  > > deliverables, with projected completion dates".
>  > >
>  > > However, I'd suggest we discuss this as if it said "a list of
>  > > prioritized list deliverables".  From a practical standpoint, it is
>  > > impossible to project completion dates until we have a good idea who
>  > > will be joining the proposed TC.  Those who do line up to join the TC
>  > > can huddle before we submit the charter and turn the prioritization 
> into
>  > > projected dates.
>  > >
>  > > So far I've heard the following items (in no particular order)
>  > >
>  > > 1) A conformance test of ODF documents and implementations, i.e., test
>  > > the formal shall's and should's, etc.
>  >
>  > Dave has asked that already: What is this exactly. A piece of software?
>  >
> 
> Sorry, I stated it too loosely.  The base deliverable is a "conformity 
> assessment methodology" (I've also heard it called a "test requirements 
> document"), a document that details the requirements of a conformance 
> testing tool.  This would mainly be a task of collecting and collating 
> the normative provisions of each ODF version, along with provisions in 
> referenced standards, and putting them in a logical order, noting 
> dependencies, assigning each one an ID, etc.  It would also define 
> scoring and reporting requirements for a conformance test.
> 
> Then, we obviously would want an implementation of that assessment 
> methodology.    The W3C develops and hosts Validators for many of their 
> tools online. However, I have not seen this done at OASIS.  I don't know 
> if this is for lack of interest or because it is somehow problematic.
> 
> But in general, whether we develop the tool in OASIS or outside of 
> OASIS, we start with the assessment methodology document.

This sounds reasonable to me.
> 
> 
>  > > 2) An Acid-style test of ODF implementations, i.e., feature and
>  > > rendering-oriented, essentially highlighting ODF features that are not
>  > > widely implemented (or implemented correctly) but are desired (by 
> whom???)
>  >
>  > As for "rendering-oriented": This is only applicable to text documents,
>  > and maybe graphical documents, but not to spreadsheets and database
>  > frontend documents (new in ODF 1.2). If we provide tests, then we should
>  > provide tests that are applicable to all kind of documents. Another
>  > issue with rendering-based tests is that rendering is system dependent.
>  > On the one hand documents may render differently because of different
>  > fonts that are installed, or different hyphenation rules, and so on. On
>  > the other hand, and more important, documents can be rendered on very
>  > different devices. On a small device, you may for instance want to
>  > render a document differently than on a desktop. In a browser, you may
>  > want to render a document without page breaks. Test cases in my opinion
>  > should consider that.
>  >
> 
> I agree.  Whatever the TC produces, whether conformance tests, acid 
> tests, interoperability tests should be traceable to a provision of the 
> ODF standard, or to a profile of the ODF standard that the proposed TC 
> creates.  There is no value in testing what is essentially 
> implementation-defined behavior.

I agree, and think this is a very import point. We can only have tests 
for things that are normatively defined by ODF or a profile. What we 
can't do is to write a test for something that is not normatively 
defined but anyway require that an application passes it. If we would do 
so, then we would define normative behavior by test cases. That's not 
reasonable, and I think even not permitted for standards.

> 
> But with spreadsheet, I could imagine some things that could work for an 
> Acid-test.  For example, couldn't you resize rows and columns and make 
> cells have color fills that make a picture?  So each cell is like a 
> pixel?  Of course, I think the average user would be more interested in 
> formula calculations than cell colors, but you could mix this.  So maybe 
> a cell does a calculation and using an IF() statement shows a character 
> or not depending on the correctness of the calculation.  You could then 
> have a passing test suite show an "ASCII Art" picture.  Weird, but it 
> could be done.

Is my understanding correct that what you test by this is not the 
rendering, but the calculation of a formula?

How would you apply this test to an application like OpenOffice.org?

> 
> So implementation guidelines for interoperability, we can certainly do 
> that, listing best practices in that area.
> 
> But I'm not sure what implementation guidelines in general would look 
> like.  Any ideas  We could, for example, give references that explain 
> how to accomplish certain tasks in ODF.  So, for bezier curves we give a 
> reference to an article that explains the most efficient way to do the 
> calculations, etc.  But this seems like a lot of work that might not 
> have an audience.  ODF is really an encoding of conventional office 
> documents.  The applications already know how to do all these things. 
>  They just, for the most part, need to figure out how to encode it in 
> ODF.  So, text on "How to write a spreadsheet" would be overkill.  But 
> "How to add ODF support to your Application" might be useful.
> 

I agree to this, in particular to your suggestion to limit the scope to 
"How to add ODF support to your Application". So, the idea was actually 
that the TC itself does not start itself to think about areas where such 
guidelines are required, but that there is a forum where implementors 
can share their experience. The TC may use the forum to identify ares of 
interests, but maybe also to transform guidance that is provided in the 
forum into a document, that then may become a deliverable of the TC.

Another way to provide guidance to implementors could be sample 
documents for a particular feature. This could be very similar to test 
documents, except that the test is not used to measure conformance, but 
to provide guidance how a reasonable implementation could look like. 
Implementors could follow these guidelines, or not.

Michael

-- 
Michael Brauer, Technical Architect Software Engineering
StarOffice/OpenOffice.org
Sun Microsystems GmbH             Nagelsweg 55
D-20097 Hamburg, Germany          michael.brauer@sun.com
http://sun.com/staroffice         +49 40 23646 500
http://blogs.sun.com/GullFOSS

Sitz der Gesellschaft: Sun Microsystems GmbH, Sonnenallee 1,
	   D-85551 Kirchheim-Heimstetten
Amtsgericht Muenchen: HRB 161028
Geschaeftsfuehrer: Thomas Schroeder, Wolfgang Engels, Dr. Roland Boemer
Vorsitzender des Aufsichtsrates: Martin Haering