OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

office-metadata message

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


Subject: IRC meeting minutes - 05/23


Here are the rough IRC notes we made during the call.

Svante





Session Start: Wed May 23 00:00:00 2007
Session Ident: #odf-metadata
[Wed:16:57:20] * Svante is now known as Svante_
[Wed:16:57:46] * Svante has joined #odf-metadata
[Wed:16:58:09] * Svante_ sets mode: +o Svante
[Wed:17:02:57] * pdurusau has joined #odf-metadata
[Wed:17:04:47] * darcusb has joined #odf-metadata
[Wed:17:10:55] <Svante> 1 Issues List	3
[Wed:17:10:56] <Svante> 1.1 RDF:Type on <odf:element>	3
[Wed:17:10:56] <Svante> 1.2 Elements with xml:id Metadata	3
[Wed:17:10:56] <Svante> 1.3 Ordering of Elements with xml:id	3
[Wed:17:10:56] <Svante> 1.4 File Types: Renaming to rdf:type	4
[Wed:17:10:56] <Svante> 1.5 Binding Files To RDF Applications	4
[Wed:17:10:58] <Svante> 1.6 OpenDocument Elements: Binding to a File	4
[Wed:17:11:00] <Svante> 1.7 Introduction of odf:mimeType property for odf:Files	4
[Wed:17:11:22] <Svante> .
[Wed:17:11:25] <Svante> 1.1
[Wed:17:11:25] <Svante> RDF:Type on <odf:element>
[Wed:17:11:25] <Svante> Should rdf:type be added to <odf:element> element node? (Svante Schubert)
[Wed:17:11:25] <Svante> It has been previously agreed that <odf:file> element should have an optional attribute of rdf:type. The proposal is to add the same attribute to <odf:element>. 
[Wed:17:11:25] <Svante> Resolution:
[Wed:17:12:45] <Svante> In our spec:
[Wed:17:12:46] <Svante> One or more <rdf:type> property elements specify the metadata type of a metadata file.
[Wed:17:16:49] <Svante> Patrick suggests to make the above statement a note.
[Wed:17:20:06] * EliasT has joined #odf-metadata
[Wed:17:20:15] <EliasT> I'm here!
[Wed:17:20:27] <Svante> Hi
[Wed:17:20:28] <Svante> .
[Wed:17:20:34] <EliasT> sorry.. I couldn't get out of the previous meeting.
[Wed:17:20:40] <EliasT> calling in
[Wed:17:20:43] <Svante> 1.2 Elements with xml:id Metadata
[Wed:17:20:43] <Svante> Should the elements, table-table-column, table-table-row, table-table-cell, chart-plotting-area, chart-series, chart-data-point, meta-text, and section, be added to the list of elements that take xml:id, with the appropriate schema modifications? (Svnate Schubert)
[Wed:17:20:43] <Svante> It is proposed that these elements be added to those already present in the proposal (table-table, draw-image, text:bookmark, text:bookmark-start, text:bookmark-end, heading, and paragraph.)
[Wed:17:20:43] <Svante> The main purpose of these additions is to enable greater use of metadata for accessibility. 
[Wed:17:20:45] <Svante> Resolution:
[Wed:17:21:26] <EliasT> +1 to that proposal
[Wed:17:22:41] <Svante> We all agree on this
[Wed:17:23:01] <Svante> .
[Wed:17:23:02] <Svante> .
[Wed:17:23:05] <Svante> 1.3 Ordering of Elements with xml:id
[Wed:17:23:05] <Svante> Should the elements listed for the optional xml:id attribute be listed in alphabetical order? (Patrick Durusau)
[Wed:17:23:05] <Svante> This is an editorial/readability issue. The elements are listed in no particular order now and placing them in alphabetical order would enhance the readability of the document.
[Wed:17:23:05] <Svante> Resolution:
[Wed:17:25:09] <Svante> Is the order dependent on the relaxNG examples?
[Wed:17:25:25] <Svante> As the relaxNG examples are AFIK being concatenated
[Wed:17:26:43] <Svante> Action: Svante (I) shall find out if the order is important for RelaxNG
[Wed:17:26:51] <Svante> Same problem for chapter "Elements capable of In Content Metadata"
[Wed:17:27:10] <Svante> Therefore we postpone this issue to the list.
[Wed:17:27:13] <Svante> .
[Wed:17:27:14] <Svante> .
[Wed:17:27:17] <Svante> 1.4 
[Wed:17:27:24] <darcusb> order is not significant because they can be separate statements; e.g.section &= xml-id
[Wed:17:27:24] <Svante> Binding Files To RDF Applications
[Wed:17:27:24] <Svante> The current language under File Types reads with regard to rdf:type that: “The property may be used to relate a metadata file to an RDF application.” It is proposed that the quoted language be stricken. (Patrick Durusau)
[Wed:17:27:24] <Svante> It will be possible for applications to so use rdf:type  but that should not be required by ODF.
[Wed:17:27:24] <Svante> Resolution: 
[Wed:17:29:57] <Svante> regaring 1.3: If relaxNG is not a problem (what we expect), the editors will order the items alphabetical
[Wed:17:34:28] <Svante> regarding 1.3: Regaded as minor issue, editor should sort after own will (e.g. by chapter names)
[Wed:17:34:56] <Svante> regarding 1.1: We agree on a informative note
[Wed:17:35:03] <Svante> regarding 1.1: The text could be:
[Wed:17:35:09] <Svante> "One or more <rdf:type> property elements specify the metadata type of a metadata file."
[Wed:17:35:27] <Svante> "One or more <rdf:type> property elements specify the metadata type of a metadata element."
[Wed:17:36:11] <Svante> Better: "One or more <rdf:type> properties specify the metadata type of a metadata element."
[Wed:17:37:04] <Svante> We agree on the last text beyond 'better' as informative note.
[Wed:17:37:06] <Svante> .
[Wed:17:38:15] <Svante> regarding 1.4 
[Wed:17:38:47] <Svante> I agree to leave this out and perhaps mention the possibility of binding in the example document
[Wed:17:41:40] <Svante> .
[Wed:17:41:40] <Svante> .
[Wed:17:41:46] * Svante has quit IRC (Excess Flood)
[Wed:17:41:59] * Svante has joined #odf-metadata
[Wed:17:43:18] <EliasT> odf:mime-type
[Wed:17:43:28] <Svante> odf:mimeType
[Wed:17:43:59] <Svante> as we are in a rdf domain
[Wed:17:44:01] <EliasT> odf:File
[Wed:17:44:22] <Svante> or on a subclass like odf:metaDataFile
[Wed:17:44:30] <EliasT> MetadataFile
[Wed:17:44:56] <Svante> of course
[Wed:17:46:18] <Svante> -->  http://www.w3.org/Protocols/rfc2616/rfc2616-sec3.html#sec3.7
[Wed:17:46:33] <Svante> That there is a type '/' subtye 
[Wed:17:47:20] <EliasT> is this the right one? Metadata_Model_Proposal_10May2007?
[Wed:17:48:10] <Svante> The latest will come out just after the call
[Wed:17:51:28] <Svante> Elias come up with a new RDF link -> http://www.ietf.org/rfc/rfc4288.txt
[Wed:17:51:38] <Svante> Elias come up with a new RFC link -> http://www.ietf.org/rfc/rfc4288.txt
[Wed:17:53:18] <Svante> This is the spec we have to point!
[Wed:17:53:51] <Svante> Therefore we agree on the MIME property (or mediaType property)?
[Wed:17:54:13] <EliasT> example of referencing mimereg http://www.ietf.org/rfc/rfc4287
[Wed:17:55:34] <EliasT> MIME media types [MIMEREG] MUST NOT be used
[Wed:17:55:34] <EliasT>    as values for the "type" attribute on Text constructs.
[Wed:17:56:02] <Svante> odf:mimeMediaType
[Wed:17:56:09] <Svante> odf:mimeType
[Wed:17:56:09] <EliasT> odf:mimeType
[Wed:17:56:13] <Svante> k ;-)
[Wed:17:56:26] <EliasT> mediaType?
[Wed:17:57:05] <Svante> We agree on odf:mimeType
[Wed:17:57:33] <Svante> I remove the element beyond property and adapt the comment text to MIME media type
[Wed:17:57:46] <Svante> We all agree on the property
[Wed:17:57:56] <Svante> .
[Wed:17:57:56] <Svante> .
[Wed:17:57:58] <Svante> 1.6 Renaming RDF property odf:content to odf:stringValue
[Wed:17:57:58] <Svante> Renaming the RDF property, which specifies the RDF Literal from an ODF element with an xml:id from “odf:content” to “odf:stringValue”. This is unambigous as always the literal value is meant and not the XML content of the element. 
[Wed:17:59:35] <EliasT> odf:data-type odf:data-value
[Wed:17:59:52] <Svante> Yes, these are attributes on the ODF element
[Wed:18:00:07] <Svante> The odf:content an RDF property only in the memory model
[Wed:18:02:01] <EliasT> <text:span xml:id="foo">bar</text:span>
[Wed:18:02:30] <EliasT> content.xml#foo is equiv some IRI <urn:foo>
[Wed:18:02:46] <EliasT> <urn:foo> ex:writtenIn "English" .
[Wed:18:03:33] <Svante> Left IRI urn:foo represents the element in the ODF content
[Wed:18:03:54] <EliasT> furthermore, the predicate might really want to say the "content" of the ODF element.
[Wed:18:04:29] <EliasT> <urn:foo> odf:content "bar"
[Wed:18:05:17] <Svante> To separate the Literal from an XMLLiteral by using more explicit property than odf:content like odf:stringValue
[Wed:18:05:31] <EliasT> <urn:foo> odf:content "bar"^^rdf:XMLLiteral
[Wed:18:05:44] <EliasT> <urn:foo> odf:content "bar<foo>whatever</foo>"^^rdf:XMLLiteral
[Wed:18:06:53] <Svante> It defaults to string, but will be differentiated by the type
[Wed:18:07:45] <Svante> We dont have to put the type into the property name
[Wed:18:07:48] <EliasT> contentXML and contentString
[Wed:18:07:52] <EliasT> we don't need the ones above
[Wed:18:07:53] <Svante> Therefore we stick on odf:content


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