RE: [oic] test documents and being smart with meta-data

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

Not stating a preference from here at this point.  Nice list and much to
think about.

I would consider, for (d), that depending on the situation, one can also
have descriptive text in the document that also exercises the particular
feature to be demonstrated/confirmed. 

Most of the documents that I make to confirm something start out having text
that describes the case at hand with comments on my progress through
whatever scenario I am employing (in the case of a test on interoperability
between products and/or formats).

 - Dennis

PS: When I send such materials around, and when I archive them on a web
site, I usually package the document package in a Zip with companion
material, manifest, metadata, screen shots, notes, etc.  I suppose that is a
hybrid of (e-f).  I'm going to practice with some I already have done.

-----Original Message-----
From: Hanssens Bart [mailto:Bart.Hanssens@fedict.be] 
http://lists.oasis-open.org/archives/oic/200810/msg00026.html
Sent: Friday, October 31, 2008 10:04
To: oic@lists.oasis-open.org
Subject: [oic] test documents and being smart with meta-data

Hi,


During the last call, we discussed about creating test documents
and reusing them since most of them can be used for testing ODF
1.0, 1.1 and 1.2.
The outcome was that we should be smart with metadata, so we can
tag the docs and let some script assemble the 1.0, 1.1, 1.2 sets.


There are various ways to do this, like:

[ ... ]

d) Add this version info in the meta info of the document itself
Pro: very easy and quick to do
Pro: you don't have to deal with other tools / hacks
Con: this would actually make atomic tests a little bit dirtier
(probably nitpicking, you could remove the data using a script
when you really want to remove every bit not part of the test)

Options:
d1) Using ODF's metadata functionality
d2) Adding elements in a separate namespace


e) Add this info in the package, in a separate file
Pro: somewhat cleaner than previous (since it should be ignored)
Con: ODF doesn't require a package (although most -  or all ? -
applications do)


f) create metadata docs, completely separate from ODF documents
Pro: clean solution
Con: very cumbersome to maintain


g) ??


Suggestions ? Remarks ? :-) Personally, I would opt for d1 or d2,
but thats's just my two cents...


Best regards,

Bart