[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: IRC meeting minutes - 05/30
Here are the rough IRC notes we made during the call. Participants on IRC: Elias Torres Gary Edwards Patrick Durusau Svante Schubert Participants on phone: Gary Edwards John Madden Patrick Durusau Svante Schubert Note: In the end of the log - just after the call - Elias confirmed that in content RDF is the only way to use content literals as metadata without duplicating them in the RDF/XML files. Svante
Session Start: Wed May 30 10:50:08 2007 Session Ident: #odf-metadata [Wed:16:59:38] * EliasT has joined #odf-metadata [Wed:16:59:43] <EliasT> hi Svante, [Wed:16:59:49] <Svante> Hi Elias [Wed:16:59:50] <EliasT> I'm overloaded with work, but I'll stay here on IM [Wed:16:59:56] <EliasT> if you have any questions.. [Wed:17:00:15] <Svante> Ok. Thanks for coming [Wed:17:05:37] * patrick has joined #odf-metadata [Wed:17:11:34] * garyedwards has joined #odf-metadata [Wed:17:12:35] <Svante> Our issue list of today: [Wed:17:12:36] <Svante> Issues List [Wed:17:12:36] <Svante> 1.7 PathName in the Manifest [Wed:17:12:36] <Svante> 1.8 in the content vs. in content [Wed:17:12:36] <Svante> 1.9 Redefinition of Content for text:bookmark-start [Wed:17:12:36] <Svante> 1.10 Standalone element <text:bookmark/> should not be alloed to use in-content attributes [Wed:17:12:36] <Svante> 1.11 Removal of the word 'Root element' [Wed:17:13:03] <Svante> . [Wed:17:13:10] <Svante> 1.7 PathName in the Manifest [Wed:17:13:10] <Svante> In section 1.1.1 Declaration of Metadata Files in the Metadata Manifest, the following reference occurs to the metadata manifest file: “The metadata manifest file shall be stored at the pathname /manifest.rdf.” [Wed:17:13:10] <Svante> That is incorrect. A pathname does not include a filename. The path should be defined with reference to the ODF package and separately the name of the manifest file defined. [Wed:17:13:10] <Svante> (Patrick Durusau) [Wed:17:13:10] <Svante> Resolution [Wed:17:13:27] <Svante> . [Wed:17:15:58] <Svante> The metadata manifest file is stored as '/'. The metadata manifest file shall be named "manifest.rdf". [Wed:17:16:17] <Svante> Patrick suggested wording ^^ [Wed:17:16:33] <Svante> . [Wed:17:16:56] <Svante> Next issue 1.8 [Wed:17:16:57] <Svante> in the content vs. in content [Wed:17:16:57] <Svante> Minor editorial change. In 1 and 1.1, the phrase “in the content of the document” is used. [Wed:17:16:57] <Svante> (Patrick Durusau) [Wed:17:16:57] <Svante> Suggest simply “in content of the document.” [Wed:17:16:57] <Svante> Resolution: [Wed:17:17:21] <Svante> all: No objections from the group [Wed:17:17:27] <Svante> . [Wed:17:17:31] <Svante> Next issue 1.9 [Wed:17:17:40] <Svante> Redefinition of Content for text:bookmark-start [Wed:17:17:40] <Svante> Usually xml:id and m:about/m:property refer to the content of the OpenDocument element, that is not correct for text:bookmark-start, which is a stand-alone element. (John Madden) [Wed:17:17:40] <Svante> On two locations we reconsider wording: 1.2.2 mentioning "...the literal content of the OpenDocument element" and 1.1.1 "...the content literal of the OpenDocument element the RDF object." [Wed:17:17:40] <Svante> Suggestion: Add “..in case of bookmarks the RDF literal is between the text:bookmark-start and text:bookmark-end element.” [Wed:17:17:40] <Svante> Resolution: [Wed:17:23:19] <Svante> Patrick suggestion to add: "In the case of bookmarks the content literal is between <text:bookmark-start/> and text:bookmark-end/>," [Wed:17:23:49] <Svante> Suggested wording: In the case of bookmarks the content literal is between <text:bookmark-start/> and text:bookmark-end/>. [Wed:17:24:37] <Svante> No objections from the group. [Wed:17:24:37] <Svante> . [Wed:17:24:39] <Svante> . [Wed:17:24:46] <Svante> Next issue 1.10 [Wed:17:24:48] <Svante> Standalone element <text:bookmark/> should not be alloed to use in-content attributes [Wed:17:24:48] <Svante> Currently an empty text:bookmark element is allowed to use the in content metadata. It makes no sense to allow a m:data-value when there is no content. (Svante Schubert) [Wed:17:24:48] <Svante> Suggestion: Remove text:bookmark from the list of in-content attributes (m:about/m:property/m:data-type/m:data-value), but still allow the use of xml:id for metadata on all bookmarks. [Wed:17:24:48] <Svante> Resolution: [Wed:17:25:00] <Svante> Elias ^^ [Wed:17:25:25] <Svante> This might interest you, but it is just that we allowed metadata on an empty element. [Wed:17:25:58] <Svante> Correction ^^ [Wed:17:26:07] <Svante> This might interest you, but it is just that we allowed IN-CONTENT metadata on an empty element. [Wed:17:26:44] <Svante> Proposal: We would remove this stand-alone element from the set of in-content metadata elements [Wed:17:27:19] <EliasT> I'm here. [Wed:17:27:41] <EliasT> which element? [Wed:17:27:45] <EliasT> text:bookmark/ [Wed:17:27:47] <Svante> EliasT this is about the stand-alone bookmark elmeent [Wed:17:27:49] <Svante> yes [Wed:17:28:12] <EliasT> we allow IN-CONTENT metadata? meaning what? m:about m:property? [Wed:17:28:22] <Svante> Which has not text content, what was mistakenly assumed earlier. Yes, currently we do [Wed:17:28:27] <Svante> We want to fix that [Wed:17:28:44] <EliasT> only allow what? [Wed:17:28:46] <EliasT> xml:id? [Wed:17:29:03] <Svante> Yes, to allow metadata on all possible bookmarks [Wed:17:29:15] <EliasT> sounds good. if that's what bookmark is used for... [Wed:17:29:23] <EliasT> let's attach metadata to the bookmark not its content [Wed:17:29:41] <EliasT> we can later solve the problem of attaching metadata to the content of the bookmark. [Wed:17:29:52] <EliasT> did I understand the issue correctly? [Wed:17:30:23] <Svante> The bookmark-start and bookmark-end still have in content metadata, but not the stand-alone marker. [Wed:17:31:04] <EliasT> examples of all of those three? [Wed:17:31:14] <EliasT> a short one.. [Wed:17:32:06] <Svante> SemiShort -> [Wed:17:32:07] <Svante> <text:p> [Wed:17:32:07] <Svante> <text:bookmark-start text:name="Mark 1" xml:id="ID_SELECTION"/> First part selection [Wed:17:32:07] <Svante> </text:p> [Wed:17:32:07] <Svante> <text:p text:style-name="P1"> [Wed:17:32:07] <Svante> Middle part of selection [Wed:17:32:07] <Svante> </text:p> [Wed:17:32:07] <Svante> <text:p text:style-name="P1"> [Wed:17:32:07] <Svante> Last part of selections [Wed:17:32:07] <Svante> <text:bookmark-end text:name="Mark 1"/> [Wed:17:32:07] <Svante> </text:p> [Wed:17:32:31] <Svante> Three paragraphs where the content is embraced by bookmarks (end/start) version [Wed:17:33:21] <Svante> Stand alone version: [Wed:17:33:22] <Svante> <text:p text:style-name="P1"> [Wed:17:33:22] <Svante> Important note <text:bookmark text:name="I-Note"/> [Wed:17:33:22] <Svante> </text:p> [Wed:17:33:48] <Svante> Just a 'jump address' for the application [Wed:17:34:33] <Svante> The above would allow xml:id and in-content metadata the latter standalone one xml:id (to be able use bookmarks all together in a metadata scenario describing bookmarks). [Wed:17:35:36] <Svante> EliasT? Does this clarify the difference and the reason for our chance? [Wed:17:38:19] <Svante> Exchange the line with bookmark-start above with the following: [Wed:17:38:20] <Svante> <text:bookmark-start text:name="Mark 1" m:about="someIRI" m:property="someIRI" xml:id="ID_SELECTION"/> First part selection [Wed:17:38:46] <Svante> Now it has m:about/m:property, which is still allowed [Wed:17:39:28] <EliasT> I'm back. [Wed:17:39:30] <EliasT> sorry sorry [Wed:17:39:34] <EliasT> looking [Wed:17:40:03] <EliasT> why does start and end need content? [Wed:17:40:21] <EliasT> what's object literal for? [Wed:17:40:28] <EliasT> <text:bookmark-start text:name="Mark 1" m:about="someIRI" m:property="someIRI" xml:id="ID_SELECTION"/> [Wed:17:40:31] <EliasT> in that one [Wed:17:41:43] <Svante> The content between start and end [Wed:17:42:36] <EliasT> and end? [Wed:17:42:37] <Svante> Actually this was issue 1.9, where we redefined [Wed:17:42:38] <Svante> 1.1.1In the case of bookmarks the content literal is between <text:bookmark-start/> and text:bookmark-end/>, [Wed:17:42:49] <EliasT> can end have m:about and m:property? [Wed:17:43:09] <Svante> No, as it is defined by text:name [Wed:17:43:19] <Svante> No, as the binding to the start is defined by text:name [Wed:17:43:53] <Svante> And m:about/m:property/m:data-value/m:data-type and xml:id is only on start [Wed:17:44:46] <EliasT> k. soudns good to me [Wed:17:44:51] <Svante> Great! [Wed:17:44:53] <EliasT> and xml:id on standalone [Wed:17:44:59] <Svante> Exactly [Wed:17:45:11] <EliasT> good good [Wed:17:45:18] <EliasT> don't mind me.. then carry on [Wed:17:45:35] <Svante> We are through with our issue list, thank you Elias [Wed:17:45:47] <EliasT> cool [Wed:17:46:09] <Svante> Resolution 1.10: Agreement of the group [Wed:17:46:27] <Svante> One more.. [Wed:17:46:35] <Svante> Minor issue.. [Wed:17:46:38] <Svante> 1.11 Removal of the word 'Root element' [Wed:17:46:38] <Svante> From the earlier manifest description the wording “root element” still exist in a subchapter of 1.1.1 [Wed:17:46:38] <Svante> “The metadata manifest describes the metadata files of the OpenDocument package in RDF/XML. Its root element <odf:Package> represents the OpenDocument package itself. “ [Wed:17:46:38] <Svante> This is wrong as the root element could be <rdf:RDF>. (Svante Schubert) [Wed:17:46:38] <Svante> Suggestion: Remove the string “Root element”. [Wed:17:46:38] <Svante> Resolution: [Wed:17:47:41] <Svante> Proposal: Just removing the XML related substring "Root element" [Wed:17:47:52] <EliasT> good [Wed:17:48:34] <Svante> Resolution on 1.11 as propsed [Wed:17:48:46] <Svante> EliasT: Patrick and I are going to send out a new draft today [Wed:17:49:22] <Svante> We should sent the upcoming draft out for review, after the update today [Wed:17:50:30] <EliasT> excellent. [Wed:17:51:51] <Svante> byebye [Wed:17:52:11] <Svante> EliasT one more question from my side.. [Wed:17:52:15] <EliasT> k. [Wed:17:52:49] <Svante> Is there any way to use a literal from a ODF content without duplicating the string in RDF/XML by using the xml:id approach? [Wed:17:53:09] <EliasT> don't understand... [Wed:17:53:11] <Svante> Example: [Wed:17:53:25] <EliasT> <text:span m:about="" m:property="">foo</text:span> [Wed:17:53:25] <Svante> <text:p xml:id="id">Elias Torres</text:p> [Wed:17:53:40] <Svante> With RDFa it is the common way to solve it [Wed:17:54:04] <Svante> My question is, would there be any chance to do the same going for the xml:id approach? [Wed:17:54:20] <EliasT> haven't thought about it. [Wed:17:54:46] <Svante> As we have this odf:content property, that is used implicitly to bind the element content to the IRI (from the xml:id element) [Wed:17:55:31] <Svante> The question came up to me, when I wanted to suggest different ways in solving a problem. The problem was that a string from the ODF content was equal to a metadata literal and should not be duplicated [Wed:17:55:48] <EliasT> it shouldn't.. [Wed:17:55:55] <EliasT> it's in an in-memory model. [Wed:17:56:20] <Svante> <text:p xml:id="id">Elias Torres</text:p> [Wed:17:57:05] <Svante> Imagine that "uri:paraEliasIRI" is bound to xml:id using "id" by the metadata manifest [Wed:17:57:34] <Svante> How can I say that the content of that paragraph is a vCard:FN? [Wed:17:57:51] <Svante> It seems impossible [Wed:17:58:09] <EliasT> ah.. I see.. [Wed:17:58:21] <EliasT> that's why we need m:about m:property [Wed:17:58:24] <EliasT> that's EXACTLY why [Wed:17:58:34] <Svante> I just wanted to be sure ;-) [Wed:17:58:35] <EliasT> you trying to sovle it with xml:id is like going backwards in time. [Wed:17:58:39] <EliasT> :-) [Wed:17:58:56] <Svante> Have nice afternoon, Elias! That's all from me for today... [Wed:17:59:01] <EliasT> you're welcome! [Wed:17:59:03] <EliasT> later. [Wed:17:59:07] <EliasT> next week then [Wed:17:59:16] <Svante> yes. [Wed:17:59:24] <Svante> byebye [Wed:17:59:27] * EliasT has left #odf-metadata
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]