[PARSER] Why not add properties to type 'org-data'?

[PARSER] Why not add properties to type 'org-data'?

[Thorsten Jolitz]

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

Re: [PARSER] Why not add properties to type 'org-data'?

[Nicolas Goaziou]

Hello,

Thorsten Jolitz <tjolitz@gmail.com> writes:

> 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
> | ...)))
> `-------------------------------------------------------------------------
>
> ?

This is way beyond parser's attributions. For example, getting the right
date means that every SETUPFILE keyword should be inspected. INCLUDE
keywords too. And some macros could get expanded in the process.

Also keep in mind that some keywords, e.g. DESCRIPTION, are defined and
made special at the export framework level (see
`org-export-options-alist'). There are just regular keywords to the
parser. IOW, for the parser, there is no difference between

  #+DESRCIPTION: something

and

  #+FOO: something

At one point, I thought about combining parse tree and information
channel, much like what you're suggesting, but in `ox.el'. It would give
something like an "Org closure" wrapping both contents and environment
together.

But I discarded that idea, as it was very artificial: the minute the
closure was created, it was splitted again so it could get processed.


Regards,

-- 
Nicolas Goaziou

Re: [PARSER] Why not add properties to type 'org-data'?

[Thorsten Jolitz]

Nicolas Goaziou <n.goaziou@gmail.com> writes:

Hello,

> Thorsten Jolitz <tjolitz@gmail.com> writes:
>
>> 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
>> | ...)))
>> `-------------------------------------------------------------------------
>>
>> ?
>
> This is way beyond parser's attributions. For example, getting the right
> date means that every SETUPFILE keyword should be inspected. INCLUDE
> keywords too. And some macros could get expanded in the process.
>
> Also keep in mind that some keywords, e.g. DESCRIPTION, are defined and
> made special at the export framework level (see
> `org-export-options-alist'). There are just regular keywords to the
> parser. IOW, for the parser, there is no difference between
>
>   #+DESRCIPTION: something
>
> and
>
>   #+FOO: something
>
> At one point, I thought about combining parse tree and information
> channel, much like what you're suggesting, but in `ox.el'. It would give
> something like an "Org closure" wrapping both contents and environment
> together.
>
> But I discarded that idea, as it was very artificial: the minute the
> closure was created, it was splitted again so it could get processed.

OK, I do like the separation of parse tree and communication channel in
the exporter, and I can use the exporter to extract and put the
necessary 'org-data' DB object attributes, at the very least the file
name or a unique ID.

But sometimes, when only the parse-tree is needed, not the exporter
framework, it would indeed be useful if that highest level element the
others refer to as parent (org-data) would have some kind of unique
name/id.

What would be the cost of introducing just one single unique attribute
like:

,-------------------------------------------------------------------------
| (org-data (:input-file /my/file.org) (section (:begin 1 :end 52 ...)))
`-------------------------------------------------------------------------

or 

,-------------------------------------------------------------------------
| (org-data (:ID 08AF34b12) (section (:begin 1 :end 52 ...)))
`-------------------------------------------------------------------------

to make different parse trees distinguishable (and associated to the
parsed file)?

-- 
cheers,
Thorsten

Re: [PARSER] Why not add properties to type 'org-data'?

[Nicolas Goaziou]

Hello,

Thorsten Jolitz <tjolitz@gmail.com> writes:

> But sometimes, when only the parse-tree is needed, not the exporter
> framework, it would indeed be useful if that highest level element the
> others refer to as parent (org-data) would have some kind of unique
> name/id.
>
> What would be the cost of introducing just one single unique attribute
> like:
>
> ,-------------------------------------------------------------------------
> | (org-data (:input-file /my/file.org) (section (:begin 1 :end 52 ...)))
> `-------------------------------------------------------------------------
>
> or 
>
> ,-------------------------------------------------------------------------
> | (org-data (:ID 08AF34b12) (section (:begin 1 :end 52 ...)))
> `-------------------------------------------------------------------------
>
> to make different parse trees distinguishable (and associated to the
> parsed file)?

There is no real cost in this case. Though, note that :input-file would
not make for a unique identifier.

On the other hand, what prevents you, once you have the parse tree, from
tagging it with all the attributes you need?


Regards,

-- 
Nicolas Goaziou

Re: [PARSER] Why not add properties to type 'org-data'?

[Thorsten Jolitz]

Nicolas Goaziou <n.goaziou@gmail.com> writes:

> Hello,
>
> Thorsten Jolitz <tjolitz@gmail.com> writes:
>
>> But sometimes, when only the parse-tree is needed, not the exporter
>> framework, it would indeed be useful if that highest level element the
>> others refer to as parent (org-data) would have some kind of unique
>> name/id.
>>
>> What would be the cost of introducing just one single unique attribute
>> like:
>>
>> ,-------------------------------------------------------------------------
>> | (org-data (:input-file /my/file.org) (section (:begin 1 :end 52 ...)))
>> `-------------------------------------------------------------------------
>>
>> or 
>>
>> ,-------------------------------------------------------------------------
>> | (org-data (:ID 08AF34b12) (section (:begin 1 :end 52 ...)))
>> `-------------------------------------------------------------------------
>>
>> to make different parse trees distinguishable (and associated to the
>> parsed file)?
>
> There is no real cost in this case. Though, note that :input-file would
> not make for a unique identifier.

Yes, :input-file plus (exact) :date would probably do the job as unique
identifier(s).

> On the other hand, what prevents you, once you have the parse tree, from
> tagging it with all the attributes you need?

Nothing really, I just thought that the space after 'org-data' is a bit
wasted and that it would be generally usefull to put some unique
'parse-tree-id' there instead of just nil. 

But it may be better to keep the core functionality as clean and simple
as possible and add this kind of info later on if necessary.

-- 
cheers,
Thorsten