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

["Dave Pawson" <dave.pawson@gmail.com>]

2008/6/13  <robert_weir@us.ibm.com>:
>
> Michael.Brauer@Sun.COM wrote on 06/13/2008 07:38:55 AM:

RW:
> 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.

"Each ODF version"? You earlier suggested working from 1.0?
So would you expect 3 so far? 1.0 1.1 1.2?

Could you suggest a logical order?
Mine might be for common test groups? I.e. those that might sensibly
be run together.
What are 'scoring' requirements please Rob?






MB:
>> 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.
>>
>

RW:

> 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.


It would appear that you are talking about different subjects Rob?
Do you agree with Michael on this one? Do you understand the 'rending' aspect?
Agree it is so limited?

I'm quite confused by this response.


MB:
>> As for "not widely implemented": Most vendors implement those features
>> that are important for their users. If a feature is not widely
>> implemented, then this is a hint that the feature is maybe not so
>> important. I think we should focus on those features actually that are
>> widely used rather than on test cases where we know that the features
>> are not widely implemented.
>>
>
> In many cases, yes. It could be a deliberate choice by the vendor.

This contradicts your (RW) statement above about responding to
the ODF standard with a test spec? Are you now proposing to
restrict it in some way to an MB/Sun definition of 'implemented features'

Again I'm left confused by the politics.

>
>> > 3) A comprehensive test suite of atomic (single feature) tests
>> > 4) A formal profile of ODF for portability and archiving, aka ODF/A
>> > 5) A formal profile of ODF for browser-based applications
>> > 6) A formal profile of ODF for mobile devices
>>
MB:
>> I would suggest to combine 4-6 into a single deliverable, and add to
>> work out a definition what a profile exactly is, and how it could be
>> defined. Something like
>>
>> 6a) A definition of an "ODF profile" concept, where an "ODF profile" is
>> a well defined subset of ODF suitable to represent a certain class of
>> documents.
>> 6b) A set of ODF profiles, including but not limited to
>> - A formal profile of ODF for portability and archiving, aka ODF/A
>> - A formal profile of ODF for browser-based applications
>> - A formal profile of ODF for mobile devices
>>
>>
>
> The concept of a profile is well-defined.

I'd love to see a definition that this group can agree on. Do you have one Rob?

 The W3C does them all the time.
>  OASIS has them as well.  But it is a good point that we would benefit from
> having a document that outlines how to profile ODF.

Then do you agree that this is work for the TC, to define which profiles
will be addressed?
I.e. it is not a task for this group?






>> > What did I miss?
>>
MB:
>> What I'm missing a little bit is to provide guidance for implementors.
>> Simply speaking, the best way to achieve interoperability between ODF
>> applications is that these application implement as many of ODF as
>> possible and reasonable for the specific application, and with as little
>> bugs as possible. Tests are helpful to measure the quality of an
>> implementation, but they don't help implementors with the implementation
>> itself.
>>
>> So far we have suggestion for tests, but we do not have suggestion how
>> we can help implementors in their implementation work.

<sniip/>

RW:
> So implementation guidelines for interoperability, we can certainly do that,
> listing best practices in that area.

which is orthogonal to the MB comment I think?


>
> But I'm not sure what implementation guidelines in general would look like.

Rob, do you believe the TC should author ODF implementor guidelines,
not "how to author interop best practice guidelines", but ODF
implementor guidelilnes?



>  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.


IMHO this is a totally different ballgame.


Is anyone on this list expecting to deliver this to Michael/ the main TC?

regards







-- 
Dave Pawson
XSLT XSL-FO FAQ.
http://www.dpawson.co.uk