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: Re: [office] Discussion Requested: ODF <dc:creator> conflicts

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 <dc:*> 
elements. I agree that we do not have to cite any references for the dc 
namespace. The namespace URI here is sufficient.

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

Michael Brauer, Technical Architect Software Engineering
Sun Microsystems GmbH             Nagelsweg 55
D-20097 Hamburg, Germany          michael.brauer@sun.com
http://sun.com/staroffice         +49 40 23646 500

Sitz der Gesellschaft: Sun Microsystems GmbH, Sonnenallee 1,
	   D-85551 Kirchheim-Heimstetten
Amtsgericht Muenchen: HRB 161028
Geschaeftsfuehrer: Thomas Schroeder, Wolfgang Engels, Dr. Roland Boemer
Vorsitzender des Aufsichtsrates: Martin Haering

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