5 messages in org.oasis-open.lists.oicRE: [oic] test documents and being sm...| From | Sent On | Attachments |
|---|---|---|
| Hanssens Bart | Oct 31, 2008 10:07 am | |
| Andreas J. Guelzow | Oct 31, 2008 11:39 am | |
| robe...@us.ibm.com | Oct 31, 2008 11:43 am | |
| Hanssens Bart | Oct 31, 2008 1:02 pm | |
| Dennis E. Hamilton | Oct 31, 2008 1:58 pm |
| Subject: | RE: [oic] test documents and being smart with meta-data | |
|---|---|---|
| From: | Hanssens Bart (Bart...@fedict.be) | |
| Date: | Oct 31, 2008 1:02:07 pm | |
| List: | org.oasis-open.lists.oic | |
Title: RE: [oic] test documents and being smart with meta-data
Rob Weir wrote:
I like the internal metadata approach, though wouldn't d1 require ODF 1.2 metadata support?
Mm, not really: (ODF 1.1, part 2.2.1)
"Custom metadata are arbitrary elements inside <office:meta>. Since their semantics is not defined in this specification, conforming applications in general cannot process or display this data. Applications should preserve this data when editing the document."
Actually, the tested app doesn't even have to preserve it for our purposes, since it's only intended as an aid for some script to select the docs, zip them in one nice test suite etc. Same script could remove it, so the app doesn't even see our smart effort...
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.
That's a good point, I forgot about that.
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.
Very creative indeed. Adds some complexity for atomic tests and requires a package, but probably not an issue ? It's more or less related to e), so I would call this option e2)
Best regards,
Bart