RE: [oic] Testing Approach Decision #1: What Classes of Products Are To Be Tested?

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

On your 1.3.1 remark, I agree about implementation details and wasn't
thinking of that case.  I intended this category to mean office productivity
software that does not support ODF as its native model.  This is an
important (secondary) case, with different challenges compared with products
that are built around ODF as their default and essentially native model
(with feature set oriented entirely around representations in ODF).  (Two
obvious examples are WordPerfect and Microsoft Word.)  It is more, but not
entirely, like the case in 1.3.2 of standalone conversions from one format
to another, where model incongruity and assymetrical/non-inverted carrying
of features also come up.  (By that I include round-trip disconnects where
it comes back a different way than it went over, to the confusion of the
original source.)

I would put template engines under 1.3.3.  Would it work to have them
mentioned there?   

 - Dennis

-----Original Message-----
From: Hanssens Bart [mailto:Bart.Hanssens@fedict.be] 
http://lists.oasis-open.org/archives/oic/200901/msg00050.html
Sent: Thursday, January 22, 2009 01:47
To: dennis.hamilton@acm.org; oic@lists.oasis-open.org
Subject: RE: [oic] Testing Approach Decision #1: What Classes of Products
Are To Be Tested?

[ .. ]
http://lists.oasis-open.org/archives/oic/200901/msg00048.html
> 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.

Mmm, are you referring to products not designed to support ODF, or not
designed to handle office formats in general ?

I don't think we should make a distinction between office applications using
a converter and those who natively support ODF (hard to draw the line
anyway:
on product may need a separate plug-in, while another has it integrated in a
modular architecture for markup languages). That's an implementation
"detail"


Maybe another product class: template engines (aka mailmerge on steroids).
A bit of a niche business market, but probably with a stronger focus on
metadata, read-only features, forms and database-features.



Best regards,

Bart