OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

office message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: Discussion Requested: ODF <dc:creator> conflicts

I am requesting discussion on a problem with conflicts around <dc:creator> as it is used in ODF.  The conflicts apply to both ODF 1.1 and ODF 1.2 cd01-rev01.

I would like the discussion to proceed in two parts:

 1. Reaching agreement on the problem and need for a remedy (or not), 

 2. Depending on agreement about the problem, reaching agreement on the remedy and how it is introduced.  

Here are my current thoughts on both:



The ODF 1.1 and 1.2 (cd01-rev01) specifications make modifications to the interpretation of namespace elements under a namespace that the ODF TC and OASIS have no authority to modify.  In addition, the modification is inconsistent with the uses of the particular namespace element in different parts of the ODF specification and interferes with any intention to rely on the same elements as officially described by the legitimate authority.

PLEASE NOTE: There is an additional concern that may derail any simple resolution:  THE USE OF "namespace" BY DCMI HAS NOTHING TO DO WITH XML NAMESPACES. (see 3, below). 


1.1 In ODF 1.1 section 3.7.1, Creator, the following statement is made:

     The <dc:creator> element specifies the name of the person who last
     modified the document. The name of this element was chosen for 
     compatibility with the Dublin Core, but this definition of "creator"
     used here differs from Dublin Core, which defines creator as "An 
     entity primarily responsible for making the content of the resource." 
     In OpenDocument terminology, the last person to modify the document 
     is primarily responsible for making the content of the document.

1.2 The element at issue is, per ODF 1.1 section 1.3, Namespaces, Table 3, and per the RNG Schema, 

     <dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/";>

1.3 That is, section 3.7.1 makes an inadmissible modification of a namespace over which the ODF TC and OASIS have no authority.  (See 1.6, below, for the finesse in ODF 1.2 cd01-rev01.)

1.4 This situation is further complicated, in ODF 1.1, by the introduction of <dc:creator> as a content element of the <office:annotation> element (section 12.1).  The defined usage is provided in section 12.1.1:

     The optional <dc:creator> element described in section 3.1.7 specifies
     the author of the annotation.

In this case, it is clear that the intended interpretation is to identify the entity that created the annotation (along with the date and time of that creation), and not "the last person to modify the document."

1.5 Similarly, ODF 1.1 specifies <dc:creator> as a content element of the <office:change-info> element, defined in section 12.3 under Creator:

     The <dc:creator> element as described in section 3.1.7 specifies the 
     name of the author who changed the document.

In this case, the wording is ambiguous.  Evidently, the element is intended to identify the author of a particular change, not "the last person to modify the document."

1.6 In ODF 1.2 cd01-rev01, <cd:creator> is defined in section

     The <dc:creator> element specifies the name of the person who last 
     modified a document (<office:meta>), who created an annotation 
     (<office:annotation>), who authored a change (<office:change-info>). 

     Note: The name of this element was chosen for compatibility with 
     Dublin Core metadata, but this definition of "creator" used here 
     differs from Dublin Core, which defines creator as "An entity 
     primarily responsible for making the content of the resource."  
     In OpenDocument terminology, the last person to modify the document
     is primarily responsible for making the content of the document.

1.7 The ODF 1.2 committee draft confines the modification of the Dublin Core Element Set 1.1 namespace element to a note.  However, the descriptive statement continues to make mutually-inconsistent interpretations of the element and at least one is clearly inconsistent with the definition in the Dublin Core Metadata Set 1.1.


 2.1 In addition to it being, I believe, seriously inappropriate to redefine an element from a namespace not under OASIS and ODF TC authority, it also creates the small problem of when that namespace and its elements are desired to be used in exactly the way defined under the Dublin Core Elements 1.1 specification (for example, in arbitrary <office:meta> content elements either under the normative ODF 1.1 schema or as foreign extensions under the ODF 1.2 schema and conformance clause).  There is no technical confusion in RDF annotations, because a CURI of the form "dc:creator" is an attribute value shorthand for a URI, not an XML element or attribute name.  Consequently, the ODF interpretation can *never* be the intended interpretation of the CURI or the unabbreviated URI "http://purl.org/dc/elements/1.1/creator";.

 2.2 The <office:meta> <dc:creator> interpretation is implemented heavily in production software that supports ODF.  This has been confirmed in some feature-support inspection tests created at the OIC TC.

 2.3 One remedy is along the following lines:

   * Deprecate all use of <dc:creator> in ODF 1.2, making note of the practice in <office:meta> and the recommended replacement there.  (Note the special concerns and alternative in 3, below, and what that might require as a remedy.)

   * Add the namespace "http://purl.org/dc/terms/"; to the ODF 1.2 cd01-rev01 section 1.3 Table 4 in addition to the namespace binding for prefix "dc".  Bind the prefix "dcterm" to the DC terms namespace in the RNG Schema and throughout the exposition of the specification.  

   * In the RNG Schema and in the specification, add the element <meta:last-modifier> as a content choice of <office:meta>, defining it to serve the purpose of the deprecated <dc:creator> element here.

   * For <office:annotation> and <office:change-info> introduce <dcterm:contributor> as the replacement for the deprecated <dc:creator> content element of those elements.  Although I still have a sinking feeling about using DCMI elements here, if they are usable, <dcterm:contributor> seems to be the closest match.

   * The note about special practices in the ODF community should be ditched entirely.


Although the remedy in (2.3) may seem too drastic, I fear we have a bigger problem.  There needs to be careful analysis of the DCMI specifications and any related standards that have been promulgated concerning the use of Dublin Core terms.  Here's what worries me:

3.1 In the Dublin Core specifications, the terms "namespace" and "element" ARE NOT USED IN THE TECHNICAL XML SENSE.  The use of Namespace by DCMI is not in the sense of XML Namespace, and the use of element and the term for the element is not in the sense of an XML Namespace local name.

3.2 Now, it is common to see strings like "dc:creator" and "dcterm:contributor" in many places in XML documents, especially in RDF annotations.  THAT USAGE HAS NOTHING TO DO WITH NAMES IN XML NAMESPACES.  Those occurrences are as attribute *values* and in all cases they are CURI-coded shorthand for URIs, not names of XML-namespace members.

3.3 I thought that maybe the DCMI material simply didn't connect the dots to XML and left it to others, except there is the following very clear statement that DCMI namespace is meant and it has *nothing* to do with XML namespaces [1: section 1]:

     "This documentation is maintained by the DCMI Usage Board in 
     accordance with the DCMI Namespace Policy [NAMESPACE]. The 
     namespace policy says that DCMI terms are identified using 
     Uniform Resource Identifiers (URIs). In accordance with the
     principle that distinct URIs should be assigned to distinct 
     resources, the policy sets limits on the range of editorial 
     changes that may allowably be made to the official labels, 
     definitions, and usage comments associated with DCMI terms. 
     By policy, any changes of meaning judged 'likely to have a 
     substantial impact on either machine processing of DCMI terms
     or the functional semantics of the terms' must trigger the 
     creation of a new, distinct term with a new, distinct URI."

3.4 The DCMI Namespace Policy goes further to emphasize that this is a DCMI-specialized use of the term "namespace" [2: section 1]:

     All terms used in metadata descriptions that conform to the 
     DCMI Abstract Model [DCAM] must be assigned a unique URI. 
     For convenience, the term URIs that are assigned and managed
     by the DCMI are grouped into collections known as DCMI 
     namespaces. This document describes how term URIs are allocated
     by DCMI and the policies associated with DCMI namespaces.

3.5 So, apparently, there is no XML namespace defined by DMCI and the use of the DMCI URIs as namespace identifiers apparently has no standing as an use of Dublin Core elements.  Unless some other standard has created such an use (and using those URIs as XML namespace URIs), the use in ODF is a mistake.

3.6 Although the remedy in (2.3) might seem severe, the absence of any DMCI establishment of an XML namespace for a URI under their authority suggests that we might need to do something quite different and even more painful:

  * Deprecate all use of so-called Dublin Core XML Namespace URIs in the ODF specification (having no impact on use in RDF CURI values, however, but those uses must be accompanied by an appropriate XML namespace binding).

  * Introduce a new, OASIS authorized ODF namespace for ODF XML elements whose interpretations are specializations of Dublin Core metadata elements.

  * One might bind the new namespace to prefix "dc" as a way to smooth things over.  Just to avoid confusion, the ODF RDF metadata specification should use a different prefix for CURI use (dcterm would work and is preferable for other reasons).

3.7 If there is some standard out there that does establish authoritative use of an XML namespace identified via the DMCI URI (as opposed to merely for use in a CURI, an xmlns binding hack), would someone please find it.

Unfortunately, this is *not* an April Fools Day joke.    

[1] DCMI Usage Board.  DCMI Metadata Terms.  DCMI Recommendation, Dublin Core Metadata Initiative, 2008-01-14.  Available at <http://dublincore.org/documents/2008/01/14/dcmi-terms/>

[2] Andy Powell, Harry Wagner (eds.).  Namespace Policy for the Dublin Core Metadata Initiative (DCMI).  DCMI Recommendation, Dublin Core Metadata Initiative, 2007-07-02.  Available at <http://dublincore.org/documents/2007/07/02/dcmi-namespace/>

 - Dennis

Dennis E. Hamilton
NuovoDoc: Design for Document System Interoperability 
mailto:Dennis.Hamilton@acm.org | gsm:+1-206.779.9430 
http://NuovoDoc.com http://ODMA.info/dev/ http://nfoWorks.org 

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]