OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

oic message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [oic] Testing Approach Decision #1: What Classes of Products Are To BeTested?


"Dennis E. Hamilton" <dennis.hamilton@acm.org> wrote on 01/21/2009 
04:46:58 PM:

> 
> Here is a straw man for the first of the "First Wave of Decisions" item:
> What Classes of Products are to be Tested?
> David Marston's list is at 
> <
http://wiki.oasis-open.org/oic/TestingThoughts1/800_The_First_Wave_of_Decis

> ions>.
> 

I'm taking "products" in the specific sense discussed in "Variability in 
Specification".  In that sense, ODF 1.1 (and ODF 1.0) defines three 
specific products:

1) Conforming documents
2) Conforming applications

Applications are further split into:

2a) Those that read or write ODF
2b) Those that both read and write ODF

Although it may be natural to suggest other products, such as spreadsheets 
versus word processors, these are not really "products" in the conformance 
sense.  There is no definition of a "conformant ODF spreadsheet" that 
differs from a "conformant ODF application" in general. 

That said there are certainly a range of implementations that we might 
test against these product types, and some implementations may be 
spreadsheets while others may be word processors.  But in the conformance 
sense there is no such distinction in ODF 1.1.

But I may be entirely wrong in the above analysis.  To show that I am 
wrong, you will need to show me where conformance is defined different for 
each product where you suggest a different product exists.  For example, I 
may be wrong if we can show that there is conformance for an "ODF Package" 
that is distinct from an "ODF Document", or that an "ODF Document 
Template" has distinct conformance requirements from an "ODF Document".

Also, the above is just with respect to conformance.  For interoperability 
tests we do not need to be as strict with the products defined by the 
standard.  We have the freedom to also consider useful distinctions that 
exist in the real world, and this could easily include "products" such as 
spreadsheet documents, etc.

-Rob


> In my response, I consider 
> 
>   1.1 Primary Product Class
>   1.2 Secondary Document Formats
>   1.3 Secondary Product Classes
>   1.4 Cross-Version Interoperability
> 
> It might be useful, for discussion, to look over the four parts and then
> zero in on 1.1, Primary Product Class.
> 
>  - Dennis 
> 
> -----Original Message-----
> From: Dennis E. Hamilton [mailto:dennis.hamilton@acm.org] 
> http://lists.oasis-open.org/archives/oic/200812/msg00025.html
> Sent: Friday, December 19, 2008 21:44
> To: oic@lists.oasis-open.org
> Subject: [oic] The First Wave of Decisions: Trial Answers
> 
> In the OIC-TC Call on 2008-12-17, I said I would like to create a Wiki 
page
> on the six questions on David Marston's list (below and on page 9 of his
> slide set).  On second thought, I suggested we work on the list until we
> have something closer that we might put on a Wiki page and refine over 
time.
> Here are my tries at the six questions:
> 
>    1.   What Class(es) of Product are to be tested? 
>    2.   How to deal with profiles, SHOULD statements, optionality,
> etc. 
>    3.   Will we write Test Assertions? 
>    4.   How will we take contributions? 
>    5.   What is the policy on approvals and challenges? 
>    6.   Will there be a mix of manual and automatable test cases?
> 
> 1. WHAT CLASSES OF PRODUCTS ARE TO BE TESTED?
> 
> 1.1 PRIMARY PRODUCT CLASS
> 
> 1.1.1 The primary class of products are office-productivity software
> products for word processing, presentations, and spreadsheets.  The 
products
> are typically implemented by free-standing software programs and 
components
> of office-software suites.  The products may also operate via on-line
> application services that interact with web browsers or specialty user
> agents.
> 
> 1.1.2 The products accept, manipulate, and produce one or more of the
> individual OpenDocument Format document types and their templates for 
word
> processing (OpenDocument Text), presentations (OpenDocument 
Presentation),
> and spreadsheets (OpenDocument Spreadsheet). 
> 
> 
> 1.2 SECONDARY DOCUMENT FORMATS
> 
> There are also secondary document formats that may be supported by 
software
> in the primary product class.  The interoperable use of these 
free-standing
> formats are secondary.
> 
> 1.2.1 Additional OpenDocument Format document types and corresponding
> templates that may also be supported include drawings (OpenDocument
> Drawing), charts (OpenDocument Chart), and images (OpenDocument Image),
> although the primary product interest is in the occurrence of these 
forms as
> part of the primary OpenDocument Format document types.  Not all of 
these
> document types are known to be implemented. 
> 
> 1.2.2 In addition, there are free-standing documents and templates for
> Math-ML (OpenDocument Formula) and there is a special word-processing 
master
> document (OpenDocument Global Text).  Starting with ODF 1.2 there is 
also a
> database application for local and remote databases, using a document 
format
> (OpenDocument Base).
> 
> 1.3 SECONDARY PRODUCT CLASSES
> 
> 1.3.1 A secondary product class that may be of some concern consists of
> converters by which ODF documents are imported into programs that are 
not
> designed to support ODF, with or without separate translation into 
another
> format that is supported.  This precedes conversion in the other 
direction
> because the OIC has more to say about what the appropriate 
interpretation of
> ODF format is that what the appropriate interpretation of other formats
> might be.  This can also apply in the case of processors that are 
designed
> for earlier or later versions of the OpenDocument specification, their
> feature sets, and breaking changes between the specification.
> 
> 1.3.2 An additional secondary class would consist of converters by which
> documents in other formats are converted to a corresponding ODF format.
> 
> 1.3.3 It is assumed that there is no major concern for special-purpose
> software that emit ODF documents using a subset of ODF features for a
> specific application.  Likewise, applications that use special-purpose 
ODF
> documents as a form of custom data input are not of primary or secondary
> concern.
> 
> 1.4 CROSS-VERSION INTEROPERABILITY
> 
> The primary class tends to involve implementations at the same level of 
ODF
> Specification (e.g., one of 1.0, 1.1, 1.2, ... ).  There are also
> cross-version interoperability challenges.
> 
> 1.4.1 An important consideration for the primary class is the ability to
> successfully deal with documents that were produced in accordance with a
> different version of the OpenDocument Format standard, whether earlier 
or
> later than the version for which the primary software is designed. 
> 
> 1.4.2 The ability to exchange documents back-and-forth between different
> implementations that provide primary/default support to the same or
> different versions of the OpenDocument Format standard are also of 
concern.
> 
> 
> [ ... ]
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe from this mail list, you must leave the OASIS TC that
> generates this mail.  Follow this link to all your TCs in OASIS at:
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php 
> 



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]