RE: [oic] Test Assertions - Latest Set

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

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.  That is, what is all right in a document.  First, it is all right that there be no <dc:creator> in an <office:meta> element (and there need not be any <office:meta> element).  It is all right that there be one <dc:creator> occurrence.  It is all right that there be more than one.  I suppose it might be all right that a <dc:creator> be empty or even appear as <dc:creator /> or it should at least not be an error, although no name appears to be provided in this case.

1.1 It could be that there are might be joint/multiple creators as far as Dublin Core is concerned, but maybe not as far as being "the person who last modified the document."  That is hard to tell.  Also, the difference might be with regard to language (e.g., one is in Traditional Chinese, the other is an anglicized version).  Who knows.  

1.2 We might want to say, for interoperability, that the string value is meant to provide human-understandable text.  (I don't think there is any provision for xml:space and xml:lang, and certainly not for any formatting outside of what can be done with unadorned Unicode after white-space handling.)  But this is all very squishy.

2. I don't think it is enough of a prerequisite to say "an implementation supports the element."  I think we need to characterize the support.  

3. Document consumers. 

This is about ingesting the ODF document.

3.1 A consumer needs to tolerate the specification.  That is, none, one, or multiple occurrences of a <dc:creator> element in an <office:meta> element (if present) shall be accepted.  I think we can get that much out of the requirements for consuming a document.  That is to say, a consumer must tolerate the element.

3.2 What the consumer must do with the element is different.  How the information is to be made known and what happens when there is more than one seems far removed from the ODF 1.1 specification.   I am not even sure there is an interoperability condition here.

3.3 One might want to assess whether the information is displayable in some rather direct manner and what are testable limitations on what is successfully displayed.  There can be predicates for that.  I don't know what the Prescription Level and the Normative Source might be.

4. Document producers.

This is about making a document that is regarded as a new one (rather than manipulation of an existing one).

4.1 Supporting the element in this case would be by whether it produces <office:meta> and it includes one or more <dc:creator> elements?  If the element is not supported, I would expect that it not be produced.

4.2 If it produces a <dc:creator> element, it might be automatically produced (e.g., using logged-on-account information).  It might be specifiable through an user agent.  The interesting question is whether or not it is automatically produced and is there any external control over that.  I am not sure what we are measuring though.  Usability?  

4.3 For interoperability, I suppose there is the case that the producer emits something that a different consumer could display successfully if it were designed to do so, although it is not clear how we would characterize that in a measurable way.  (Ties in with 3.3)

4.4 If it produces multiple <dc:creator> elements, I suppose the key question is what information is provided in so doing (as opposed to them being duplicates of the same content).  Or do we suggest that there not be multiple <dc:creator> elements (or at least confirm that implementations only produce at most one, whether or not there is provision for external influence of what the value is)?

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.

5.1 In this case, one would want to know if any of the consumed <dc:creator> elements were preserved and why?  I would expect that <office:meta> <dc:creator> elements in the input document would be ignored in the creation of the output, whether the element is supported or not.

5.2 I would think the expected behavior, if this element is supported, is that whether or not there are any elements in the consumed document, if <dc:creator> elements in an <office:meta> element are produced, they are produced originally just as if this was case (4).

5.3 I would think the expected behavior, if this element is not supported, is that no <dc:creator> elements are emitted, regardless of the input.  

5.4 I can imagine processes that leave metadata intact but do other things.  I don't think such processes count as being document processors that we care about interoperability for.

5.5 There is also the case of interactive document processors/producers and what is available and what is manipulable, and what arises automatically.  We may need terms for that and have to decide how far up into interactive conduct we can go.  


 - Dennis

-----Original Message-----
From: Dennis E. Hamilton [mailto:dennis.hamilton@acm.org] 
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] 
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.

Document Description:
Zip of test assertions, test cases and test documents from
http://tools.oasis-open.org/version-control/browse/wsvn/oic/TestSuite/branches/barth/

View Document Details:
http://www.oasis-open.org/committees/document.php?document_id=32195

Download Document:  
http://www.oasis-open.org/committees/download.php/32195/svn-odf11-testsuite-2009-04-22.zip

Revision:
This document is revision #1 of svn-odf11-testsuite-2009-04-20.zip.  The
document details page referenced above will show the complete revision
history.


PLEASE NOTE:  If the above links do not work for you, your email application
may be breaking the link into two pieces.  You may be able to copy and paste
the entire link address into the address field of your web browser.

-OASIS Open Administration


---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail.  Follow this link to all your TCs in OASIS at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php