OASIS Open Document Format for Office Applications (OpenDocument) TC

On 04/02/09 14:49, robert_weir@us.ibm.com wrote:
> 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. 

I think the note is mixture of describing why we have chosen the name, 
and a description how at least some office application use that element: 
They just put the name of the person that saves a document as creator 
into the dc:creator element.

Anyway, I would argue that it should be implementation defined when this 
element is updated. An application that provides this as an editable 
data where the user enters a name probably would not do anything wrong 
here. Where are many other behaviors one could think of, that probably 
also are not wrong.

For that reason, I think we should remove that note. Since it is an 
informative note, this is something we can do without breaking anything.

> 
> 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. 

I'm not sure if we are all taking about the same reference. The ones I 
were referring to were references that describe semantics of 

I submit that the namespace URI is sufficient only if Dublin Core says that
is the proper namespace URI for Dublin Core metadata in XML.  The Guidelines
document is the authority for that.  

If there is no such authority, we should not be claiming we are using a
namespace of another specification, and we should be defining an
ODF-introduced namespace for that purpose.

I agree that the ODF implementers and ODF documents will use bindings for
the namespaces specified in ODF.  

The question here is around the legitimacy of using a URI that is not under
our authority.  This is about the validity of the ODF specification, not of
the use of it (although do we want those uses to be fruit of a poisoned
tree?).  

Fortunately, the DCMI Guidelines document that Rob references establishes
the namespace and that is indeed a normative reference.  What else could it
be?  It's not our namespace.  

If the reference is not normative, we have no business using
xmlns:dc="http://purl.org/dc/elements/1.1/" as the binding throughout the
specification and in the RNG schema, with its definitions of