RE: [oic] Test Assertions - Latest Set - Other Use Case

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

It also occured to me that there is another use case with regard to <office:meta>.  I am thinking about processes that extract metadata for maintaining external information about an ODF Document.  For example, an content-management system might rely on <office:meta> for (default) creation of CMS metadata about the document.  It is not clear how this becomes a matter of concern for the OIC work, though.

It is also conceivable that a CMS system might inject content into an <office:meta> element, although my experience is that this is generally a bad idea as an arbitrary automatic action, since it undermines the provenance of the document.

 - Dennis 

-----Original Message-----
From: Dennis E. Hamilton [mailto:dennis.hamilton@acm.org] 
http://lists.oasis-open.org/archives/oic/200904/msg00061.html
Sent: Wednesday, April 22, 2009 09:29
To: bart.hanssens@fedict.be; oic@lists.oasis-open.org
Subject: RE: [oic] Test Assertions - Latest Set

Here's a little more about my concerns, using <dc:creator> in <office:meta> as my specific example.  I'm looking at 
<http://tools.oasis-open.org/version-control/svn/oic/TestSuite/branches/barth/odf11/assertions/html/metadata-dc-creator.html>
as of OIC SVN version 78.

The current provision for the <dc:creator> element is that it may occur none or more times in an <office:meta> element.  The ODF 1.1 specification declares that the "element specifies the name of the person who last modified the document."  It is also specified that "It is application-specific how to update multiple instances of the same elements."  (These conditions appear twice, once in section 2.2 and again at the beginning of section 3.1.)

Also, I thought "target" was not a specification but something that is an implementation of a (part of a) specification.  I am going to assume that targets are (1) documents, and (2) various aspects of document processing implementations.  I think there are several different target cases here.

This is the kind of thinking I have gone through in trying to separate out what we can interpret in the specification and what we have to look elsewhere for.  In the case of optionally-supported metadata, I don't see what we can do without creating our own normative sources, and they are going to be quite different, serving as guidelines or merely something to inspect for to understand whether guidelines are even needed.

Some Targets and Prescription-Level thinking:

1. The document itself.  [ ... ]

3. Document consumers. 

This is about ingesting the ODF document.

[ ... ]

4. Document producers.

[ ... ]

5. Document processors

I am thinking specifically in the case of a consumer that is used to produce a modification of the original that is not pesented as a new-document production.

[ ... ]

 - Dennis

-----Original Message-----
From: Dennis E. Hamilton [mailto:dennis.hamilton@acm.org] 
http://lists.oasis-open.org/archives/oic/200904/msg00059.html
Sent: Wednesday, April 22, 2009 06:28
To: bart.hanssens@fedict.be; oic@lists.oasis-open.org
Subject: [oic] Test Assertions - Latest Set

I looked at these latest one (starting with my favorite, dc:creator), and I notice that the connections do not seem to hold up.

For example, the assertion is worded about what an implementation must do, as a requirement, but there is no such language in the Metadata section on implementations.

I suspect that the metadata section is mostly about the document, not a consumer, generator, or processor.

It appears that we need to be clear about what is normative with regard to the specification, what target the specification applies to (and we have to be careful about inferring a target), and then where these things are entirely optional (and may clash with non-predefined elements appealing to the same space, etc.) there has to be very careful and limited assumption about what the specification requires.

I think we will need to create normative sources of a different kind that address what one might say about interoperability as opposed to what little is required of a conformant document and even less that is required of a conforming processor. 

 - Dennis 

-----Original Message-----
From: bart.hanssens@fedict.be [mailto:bart.hanssens@fedict.be] 
http://lists.oasis-open.org/archives/oic/200904/msg00057.html
Sent: Wednesday, April 22, 2009 01:50
To: oic@lists.oasis-open.org
Subject: [oic] Groups - svn-odf11-testsuite-2009-04-22.zip uploaded

Yet another zip from the SVN.

 -- Mr. Bart Hanssens

The document revision named svn-odf11-testsuite-2009-04-22.zip has been
submitted by Mr. Bart Hanssens to the OASIS Open Document Format
Interoperability and Conformance (OIC) TC document repository.  This
document is revision #1 of svn-odf11-testsuite-2009-04-20.zip.

[ ... ]