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: metadata compatability issues

Re: the compatabiliity issue with metadata, I want to emphasize that  
we have not yet settled on a proposal. So it may well be a little  
premature to worry about, except as it may help us guide design.

However, my proposal for the model (a subset of RDF) presents the  
following issues:

Here's an example of a current metadata file:

   xmlns:xlink="http://www.w3.org/1999/xlink"; xmlns:dc="http:// 
   xmlns:ooo="http://openoffice.org/2004/office"; office:version="1.0">
     <meta:generator>OpenOffice.org/2.0$Unix OpenOffice.org_project/ 
     <meta:initial-creator>Jane Doe</meta:initial-creator>
     <dc:creator>Jane Doe</dc:creator>
     <meta:user-defined meta:name="Info 1"/>
     <meta:user-defined meta:name="Info 2"/>
     <meta:user-defined meta:name="Info 3"/>
     <meta:user-defined meta:name="Info 4"/>
     <meta:document-statistic meta:table-count="0" meta:image- 
count="0" meta:object-count="0"
       meta:page-count="1" meta:paragraph-count="3" meta:word- 
count="28" meta:character-count="197"/>

The removal of a single node -- the unncessary office:meta element --  
would make this valid RDF.

So what would removing that element do to the compatability picture?

Moving on ...

Even with that change, it would not be valid against the more  
contrained RDF syntax I have advocated [1], where I have said we  
should not suppport using attributes for properties. The reason is  
that if we are agnostic about attributes or elements (as RDF is) for  
metadata properties, then we make things more complicated for xpath- 
based tools if we allow either in arbitrary extension content.

Now, this may not matter. It may be easier to just recommend that  
developers use elements instead of attributes, but not require it. In  
that case, there's no problem.

The other thing is that we can restrict that flexibility only to  
properties in the meta or office namespaces. I guess I favor that  

Also, just to be clear, the current meta:user-defined element can go  
away or be made simpler with the enhanced metadata support. Tim  
Berners-Lee himself commented on this awhile back:


I think what he's suggesting if we still want this is something like  
this as one possibility:


Finally, if we have the new subject-predicate-object model,  
"office:document-meta" seems a bit off.  Might be better -- if not  
strictly necessary at all -- to have that root element (the type for  
the document) be dcmi:Text or some such.


[1] http://wiki.oasis-open.org/office/Metadata_Model_and_Syntax

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