From mboxrd@z Thu Jan 1 00:00:00 1970 From: Thorsten Jolitz Subject: [PARSER] Why not add properties to type 'org-data'? Date: Thu, 05 Sep 2013 17:34:12 +0200 Message-ID: <87y57be0zv.fsf@gmail.com> Mime-Version: 1.0 Content-Type: text/plain Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:55461) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VHbZq-0000KH-TO for emacs-orgmode@gnu.org; Thu, 05 Sep 2013 11:34:41 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VHbZj-0001r7-Rv for emacs-orgmode@gnu.org; Thu, 05 Sep 2013 11:34:34 -0400 Received: from plane.gmane.org ([80.91.229.3]:50329) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VHbZj-0001pz-Lz for emacs-orgmode@gnu.org; Thu, 05 Sep 2013 11:34:27 -0400 Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1VHbZe-0002c1-QF for emacs-orgmode@gnu.org; Thu, 05 Sep 2013 17:34:22 +0200 Received: from e178059067.adsl.alicedsl.de ([85.178.59.67]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 05 Sep 2013 17:34:22 +0200 Received: from tjolitz by e178059067.adsl.alicedsl.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 05 Sep 2013 17:34:22 +0200 List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org Sender: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org To: emacs-orgmode@gnu.org Hi List, why isn't some of the meta-data available from the communication channel during export (especially the environmental data) stored in a property list for the 'org-data' element type during parsing? Of course in common use org-elements are tightly bound to a certain org file, and that org file is used from Emacs, so all the meta-data is there and available. But imagine for a moment org-elements (e.g. type 'headline') are stored somewhere else in a different (DB) format. Then those headlines/subtrees are not tightly coupled with a file anymore, they can be used individually, recombined to new documents etc. - each of them becomes a individual DB object, the original containing org file is merely one of their attributes. In such a situation, it would of course be necessary to store information about the 'org-data' element each of the headline elements belonged to originally, if only to be able to reconstruct the original org file. A simple DB link from the headline to the containing 'org-data' could do this - but currently all 'org-data' objects are anonymous undistinguable objects with empty property lists. Wouldn't it make sense to replace ,---------------------------------------------- | (org-data nil (section (:begin 1 :end 52 ...))) `---------------------------------------------- with something like ,------------------------------------------------------------------------- | (org-data (:id-or-name file001 :input-file /my/file.org :author me :date | 01-01-2013 :description my planning data) (section (:begin 1 :end 52 | ...))) `------------------------------------------------------------------------- ? -- cheers, Thorsten