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

[robert_weir@us.ibm.com]

I like the internal metadata approach, though wouldn't d1 require ODF 1.2 
metadata support?

I think e is a clean approach.  I think all major implementations support 
the ODF packaging model.

But one possible concern with any approach that stores the test metadata 
in the document itself -- What happens when we mix this with document 
signatures and encryption?  Any change to the metadata would require 
changing the document, and therefore would break the integrity of the 
signature and would require re-signing.

Not a huge problem perhaps.  But something to consider.

Approach f avoids that problem.  You could do it via parallel documents. 
So foo.odt would always be accompanies by foo.xml, where foo.xml contains 
the test metadata.

Note that these approaches could be harmonized.  Look at what Adobe does 
with XMP image metadata.  It can be on the side, in a parallel file, what 
they call a "sidecar" file.  But it can also alternatively be embedded 
directly in an file, in cases where the file has a defined way of adding 
metadata, such as in JPG files.

-Rob



"Hanssens Bart" <Bart.Hanssens@fedict.be> wrote on 10/31/2008 01:04:25 PM:

> 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:
> 
> a) Create directories 1.0, 1.1, 1.2 and use symbolic links
> Pro: no additional metadata work required
> Con: works on a file system level, probably we can't do this with
> the OASIS webtool
> 
> 
> b) wait for OASIS to install Subversion or another SCM
> Pro: clean solution
> Con: not available yet, not sure when/if it becomes available
> 
> (Note: if I recall correctly, SVN doesn't support "sharing" files,
> you need to add an svn:external property or something like that)
> 
> 
> c) Insert the ODF version(s) in the "description" field of the
> document details on the OASIS website
> Pro: easy to do
> Con: some discipline is required, feels "ugly"
> 
> 
> 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...
>