[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Clarifications on the draft
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]