OASIS Open Document Format for Office Applications (OpenDocument) TC

I am requesting discussion on a problem with conflicts around 

This is all interesting, I'm sure, but I'm not seeing what the problem is. 
 Is there any application that is currently having difficulty with these 
elements, or who is unsure of what they can put down in these values?  Is 
there some interoperability problem someone is having with ODF documents 
and another Dublin Core processing application that hinges on differing 
nuances for what dc:creator means?

It really looks like this as just strings from what any program can make 
of them.  The distinction between "entity primarily responsible for making 
the content of the resource" and "the person who last modified the 
document" is entirely in the human domain.  I can't think of any existing 
word processor that is capable of distinguishing these two.  It is really 
just a librarian versus content author perspective difference.  Dublin 
core states it from the librarian/curator perspective, and ODF states it 
from the document author perspective.  But these are different sides of 
the same coin, not necessarily in conflict.

-Rob


"Dennis E. Hamilton" 

Rob,

robert_weir@us.ibm.com wrote:
> This is all interesting, I'm sure, but I'm not seeing what the problem is. 
>  Is there any application that is currently having difficulty with these 
> elements, or who is unsure of what they can put down in these values?  Is 
> there some interoperability problem someone is having with ODF documents 
> and another Dublin Core processing application that hinges on differing 
> nuances for what dc:creator means?
>
>   
I don't have an example to offer of an interoperability problem due to 
differing definitions of dc:creator.

However, I think Dennis's point remains a good one.

The issue isn't one of "is there a problem," but rather whether the ODF 
standard follows the semantics of elements and attributes in namespaces 
that it imports. The utility of namespaces hinges on standards and 
ultimately applications doing exactly that.

As I said, I don't have a demonstration of an impact on interoperability 
but that seems like an awfully slippery slope on which to base the use 
of other standards.
> It really looks like this as just strings from what any program can make 
> of them.  The distinction between "entity primarily responsible for making 
> the content of the resource" and "the person who last modified the 
> document" is entirely in the human domain.  I can't think of any existing 
> word processor that is capable of distinguishing these two.  It is really 
> just a librarian versus content author perspective difference.  Dublin 
> core states it from the librarian/curator perspective, and ODF states it 
> from the document author perspective.  But these are different sides of 
> the same coin, not necessarily in conflict.
>
>   
Well, but when we define some element/attribute in ODF, I do rather hope 
that anyone who imports the ODF namespace will use our definitions and 
not simply make up ones they like better.

It seems to me to be a question of reciprocity, that is if we expect 
others to follow our work in our namespace, then we really need to 
extend that courtesy to others.

Hope you are having a great day!

Patrick
> -Rob
>
>
> "Dennis E. Hamilton" 

Patrick Durusau 

Please read section 3 of my original note:

"Dennis E. Hamilton" 

Wonderful!

We need to refer to that.  It is very important that we refer to that and
not other DCMI documents, because DCMI has removed the XML provision from
its latest DCMI Namespace policy.

Here's the glitch:

1. This document you link (thank you, thank you, a thousand thanks) is a
DCMI recommendation, Guidelines for implementing Dublin Core in XML, that
was issued on 2003-04-02,

Hi Dennis,

On 04/02/09 02:49, Dennis E. Hamilton wrote:
> Wonderful!
> 
> We need to refer to that.  It is very important that we refer to that and
> not other DCMI documents, because DCMI has removed the XML provision from
> its latest DCMI Namespace policy.

Well, this document does describe how DCMI should be used within XML, 
and therefore explains why ODF is using DCMI in the way it is using it. 
But is this what we should refer to in the ODF specification? Isn't the 
specification we have to cite here the one that describes the semantics 
of elements, and isn't this

http://www.dublincore.org/documents/dces/

that is, the one we are citing right now?

> OK, good.  Now we're simply back to discussion on whether the inconsistent
> specializations of 

Michael.Brauer@Sun.COM wrote on 04/02/2009 03:14:20 AM:

> 
> On 04/02/09 02:49, Dennis E. Hamilton wrote:
> > Wonderful!
> > 
> > We need to refer to that.  It is very important that we refer to that 
and
> > not other DCMI documents, because DCMI has removed the XML provision 
from
> > its latest DCMI Namespace policy.
> 
> Well, this document does describe how DCMI should be used within XML, 
> and therefore explains why ODF is using DCMI in the way it is using it. 
> But is this what we should refer to in the ODF specification? Isn't the 
> specification we have to cite here the one that describes the semantics 
> of elements, and isn't this
> 
> http://www.dublincore.org/documents/dces/
> 
> that is, the one we are citing right now?
> 


I think the question to ask is:  Does the reference explain _why_ we made 
the choice we did?  Or does it state _what is required_ of a conformant 
ODF document or ODF Producer/Consumer?  If a reference is justifying our 
design choice, or providing a design rationale, then it is not really a 
normative reference.  We might have an informative reference for that if 
we want, but that is purely optional.  But if something defines a 
requirement for a document, producer, or consumer, then it requires a 
normative reference. 

The use of a particular namespace for Dublin Core is already required by 
our schema.  We don't need to cite any further authority than that.  The 
fact that it is in synch with the Guidelines is great.  But from the 
perspective of an ODF document/producer/consumer, they use that namespace 
because the ODF schema defines it so. 

-Rob

Michael,

1. WHY THE GUIDELINES ARE BETTER

It is important to cite the Guidelines for use in XML because what we are
doing is using Dublin Core in XML (not RDF, the primary application of
Dublin Core for the Semantic Web).  

The DCMI XML Guidelines document makes sufficient reference to the semantics
and other aspects of the Dublin Core Element Set 1.1 (and later ones), so it
is an appropriate way to be specific about the ODF reliance on Dublin Core
in elements like 

Hi Dennis,

On 04/02/09 19:21, Dennis E. Hamilton wrote:
> Michael,
> 
> 1. WHY THE GUIDELINES ARE BETTER
> 
> It is important to cite the Guidelines for use in XML because what we are
> doing is using Dublin Core in XML (not RDF, the primary application of
> Dublin Core for the Semantic Web).  

My understanding is that these guidelines contain guidelines only for 
the schema design phase, but none for the phase at which instances using 
that schema are created or processed.

Take for instance the first three recommendation:

 > Recommendation 1. Implementors should base their XML applications on
 > XML Schemas [XMLSCHEMA] rather than XML DTDs.
 > Recommendation 2. Implementors should use XML Namespaces [XMLNS] to
 > uniquely identify DC elements, element refinements and encoding
 > schemes.
 > Recommendation 3. Implementors should encode properties as XML
 > elements and values as the content of those elements.

These are all recommendations we have followed for ODF when designing 
the ODF schema (well, we use RNG rather than XSD, but I think the main 
advice here is not use use DTDs).
Now, that we have the schema, no implementor of ODF ever has to care 
about these recommendations any longer. They are implemented in ODF 
itself already.

> 
> The DCMI XML Guidelines document makes sufficient reference to the semantics
> and other aspects of the Dublin Core Element Set 1.1 (and later ones), so it
> is an appropriate way to be specific about the ODF reliance on Dublin Core
> in elements like