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 Be Tested?


I didn't understand "class of product" in the sense of "class of
conformance" or "conformance target" at all, if that is what you are driving
at.

I was going by what ODF has been offered for and what it claims that target
to be and where one would expect interoperability.  

I am not clear what you are objecting too.  I do not mean to suggest that
there is anything different with regard to the conformance of the documents
they process and the conformance of that processing.  I do think, in terms
of the state of interoperability, the practical concerns are specific to
document types and these classes of product.  I saw this as part of focusing
on where interoperability concerns exist.

We should certainly clarify what we mean by "class of product" and whether
we will have more than one sense of that (and find a way to be clear which
one we intend in what context).  I can't imagine not distinguishing classes
of products in the world in terms of where the focus is (or is desired) for
interoperability.  I thought that was how we wanted to guide our focus on
conformance details.

Furthermore, I don't understand your objection to the recognized and
required document types that ODF defines.  Those distinctions are wired into
the ODF 1.0/1.1 specifications, as well as I can tell, and I know of nothing
in the ODF 1.2 work that is changing that.  I don't know whether OpenFormula
introduces any distinct conformance requirements, but in the case of ODF 1.1
I agree that the conformance requirements are the same for all and any of
the recognized document types.  I'm not so sure about .oth and some others
that either receive no mention at all in the normative body of the ODF 1.1
specification, or are mentioned and left largely unspecified.

 - Dennis

PS: I continue to separate application from the software that may be an
instrument of that application.  (Or, put another way, for me application
software is not the application, it is software intended to support a class
of application.)  I shall never give up on keeping the two separate.  If you
require different terms for maintaining the distinction, let me know.  I
think the distinction is crucial.  

PPS: I also can be careless in how I use "application."  I'm training myself
to be more careful.

	-	-	-	-	-	-	-	-	-

A. WHY I THINK OF THOSE CLASSES OF PRODUCTS (BOTH FORMATS AND SOFTWARE)

1. It is the Open Document Format for Office Applications

2. In section 1.1 (ODF 1.1),

This document defines an XML schema for office applications and its
semantics. The schema is suitable for office documents, including text
documents, spreadsheets, charts and graphical documents like drawings or
presentations, but is not restricted to these kinds of documents.

The schema provides for high-level information suitable for editing
documents. It defines suitable XML structures for office documents and is
friendly to transformations using XSLT or similar XML-based tools. 

3. From the Charter of the ODF TC, as last amended,

3.1 The purpose of this TC is to create an open, XML-based file format
specification for office applications.

The resulting file format must meet the following requirements:

  1. it must be suitable for office documents containing text, spreadsheets,
charts, and graphical documents, 

  [ ... ]

3.2 Scope

Since the OpenOffice.org XML format specification was developed to meet
these criteria and has proven its value in real life, this TC will use it as
the basis for its work.

A standard for office document processing and interchange will be of great
utility to many users and software companies developing applications, and
should be made available as soon as possible.

	-	-	-	-	-	-	-	-

I understand that the characteristics of such products we are concerned
about is their support for ODF documents on behalf of office applications
(which for me are what office workers are concerned with and use those
products for in their work).

I do confess to looking at interoperability as having to be situated, even
as we speak of general office-document creation, collaboration, and
interchange.

Maybe we should have Marston's feedback on what he had in mind for Classes
of Product, because I can't tell anything specific from my notes or the
slides to suggest he was talking about Conformance Targets.

And, either way, I do think we need to have some sort of clarification like
this with regard to the state of interoperability.


B. ABOUT THE DISTINCT ODF DOCUMENT TYPES

Finally, while I agree there is a single specification for several document
types, there are indeed distinct document types, called out in the
specification.  Section 2.3 Body Elements and Document Types is pretty clear
about this.  

I am referring to those types, which can occur independently and be
processed independently.  So there are indeed conformant ODF text documents
and ODF spreadsheet documents as well-defined divisions of conformant ODF
document, driven by the correspondence of MIME type and the required single
element of the required <office:body> element within content.xml.  

Not only is it the practice to speak of these types separately, but it is
also commonplace that they have separate components for their processing
when integrated in an office suite.  It is also common practice in office
applications that one must commit oneself to a type of document at the
commencement of document creation (with some exceptions for templates and
master text documents), and the current division of document types requires
such a decision to be made too.

I am recognizing that characteristic of ODF 1.1 and how it is encountered in
practice.  What's wrong with that?  Won't each of the majority of test
documents necessarily be one of the main three types?

 - Dennis
 

-----Original Message-----
From: robert_weir@us.ibm.com [mailto:robert_weir@us.ibm.com] 
http://lists.oasis-open.org/archives/oic/200901/msg00054.html
Sent: Thursday, January 22, 2009 12:10
To: oic@lists.oasis-open.org
Subject: Re: [oic] Testing Approach Decision #1: What Classes of Products
Are To Be Tested?

"Dennis E. Hamilton" <dennis.hamilton@acm.org> wrote on 01/21/2009 
04:46:58 PM:
http://lists.oasis-open.org/archives/oic/200901/msg00048.html
> 
> 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_Decisi
ons>.
> 

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


[ ... ]



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