Clarifications on the draft

[Svante Schubert <Svante.Schubert@Sun.COM>]

A list of the changes to be reviewed from the SC:

a) Namespaces:
We will suggest the TC to introduce the following three new namespaces

For metadata attributes in the content:
xmlns:m="http://docs.oasis-open.org/office/2007/03/meta#";
For the attributes m:about, m:property, m:datatype, m:content

For the RDF/XML metadata manifest:
xmlns:mm="http://docs.oasis-open.org/office/2007/03/meta/manifest#";
The elements mm:Manifest and mm:Entry.

For RDF predicates describing ODF characteristics:
xmlns:odf="http://docs.oasis-open.org/office/2007/03/meta/opendocument#";
for the element odf:Element and the attributes odf:path, odf:id


b) Using QNames in Attribute Values of ODF content

In favor of XML tools we are not defining the usage of QNames in this 
version for the above mentioned metadata attributes.
We are not giving examples as the following:
<text:p m:about="http:ex.net/1" m:property="dc:date" 
m:datatype="xsd:date" m:content="2002-10-12">October 12, 2002</text:p>.

I suggest to discuss further possibilities after this draft. There are 
two interesting links:
- The RDFa W3C WD allow to use QNames in xml values 
http://www.w3.org/TR/xhtml-rdfa-primer/#id2259644. Does the WG plan to 
resolve them via XML tools?
- http://www.w3.org/2001/tag/doc/qnameids.html

Do we agree on this or is there a different majority in the SC?


c) Data type / Data value
As the data type always have to be an IRI, the SC were more in favor to 
introduce a attribute solely using IRI (on the IRC m:datatype was 
suggested).
Instead of 'm:content' as suggested in the IRC, I would prefer 
m:data-value as in the Office we often use 'value' to define this semantic.
I would therefore propose to name the attributes m:data-type and 
m:data-value!


d) Elements for this version bearing xml:id / m:about / m:property / 
m:data-type / m:data-value
As in this version m:about and m:property will define a RDF literal by 
default and not a XML subtree to raise the bar too high for Offices 
implementing metadata,
I suggest to attach the literal describing attributes to those elements 
of the list, which may have text-content as direct child content

Elements using xml:id
    images (draw:image)
    tables (table:table)
    table-cells (table:table-cell)

Elements using xml:id / m:about / m:property
    paragraphs (text:p)
    headings (text:h)
    bookmarks (text:bookmark, text:bookmark-start, text:bookmark-end)
    metadata span (text:meta) - instead of text:span

Elements using xml:id / m:about / m:property / m:data-type / m:data-value
    text:meta-field

A final important very late question:
Do we really need the attributes m:about / m:property on all above 
elements to extract the RDF literal (the contained text) or would it not 
ease the implementation a lot to allow m:about/m:property only on 
text:meta. We would avoid redundant representation as we would hardly 
know what text has been specified. For example using text in a cell as 
RDF literal.
Is it the text of the cell....

<table:cell m:about="http://example.employee 
m:property="http://example.salary";>
    <text:p>
       <text:meta>20000</text:meta>
    </text:p>
</table:cell>

or the text of the paragraph of the cell...

<table:cell>
    <text:p m:about="http://example.employee 
m:property="http://example.salary";>
       <text:meta>20000</text:meta>
    </text:p>
</table:cell>

or the text of some text:meta of the paragraph of the cell.

<table:cell>
    <text:p>
       <text:meta m:about="http://example.employee 
m:property="http://example.salary";>20000</text:meta>
    </text:p>  
</table:cell>

Keeping it simple with text:meta might be a safe first step to avoid 
complications as we do not have experience with implementations at this 
time.
I do not insist on this, I just felt the need to point this out. Sorry, 
for questioning this so late..

Svante