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