the "right way" to build OMPL export and import

the "right way" to build OMPL export and import

[Alexis Gallagher]

Hi,

I would love to be able to export org documents to opal, so that I can read them with the various commercial outlining apps on platforms without emacs -- e.g, iOS. The ideal thing would be if I could import OPML as well.

Is anyone working on this already?

If not, does anyone have any pointers on the "right way" to go about this, so that the work would go smoothly and be acceptable upstream? This seems like a good time to ask given the recent consolidation of export facilities around the internal parser org-element.el.

I presume any OPML exporter should be based on that, correct? Is any one of the existing exporters a particularly clean example to work from?

For OPML import, is org-element-interpret-data the best starting point?

Alexis

Re: the "right way" to build OMPL export and import

[Eric Abrahamsen]

Alexis Gallagher <alexis@alexisgallagher.com> writes:

> Hi,
>
> I would love to be able to export org documents to opal, so that I can
> read them with the various commercial outlining apps on platforms
> without emacs -- e.g, iOS. The ideal thing would be if I could import
> OPML as well.
>
> Is anyone working on this already?
>
> If not, does anyone have any pointers on the "right way" to go about
> this, so that the work would go smoothly and be acceptable upstream?
> This seems like a good time to ask given the recent consolidation of
> export facilities around the internal parser org-element.el.
>
> I presume any OPML exporter should be based on that, correct? Is any one of the existing exporters a particularly clean example to work from?
>
> For OPML import, is org-element-interpret-data the best starting point?
>
> Alexis

Hi Alexis,

I guess the first step to making an OPML exporter would be figuring out
how to export correctly to XML, which happens to be something I've spent
a whole fourteen minutes thinking about. I'm not sure the general export
engine is going to be of much use, since XML is so completely flexible,
but you'll definitely want to build it on top of the internal parser.

Luckily, the parser turns an org subtree into a parse tree, and the
function `xml-print' turns a parse tree into XML. They're not quite the
same parse tree, but I guess you'll want to do something like this:

#+BEGIN_SRC org
  ,* My Great Playlist
  ,** The Cold Cold Ground.mp3
  :PROPERTIES:
  :OPML_TYPE: song
  :OPML_F:   Tom Waits - The Cold Cold Ground
  :END:
  ,** Don't Eat the Yellow Snow.mp3
  :PROPERTIES:
  :OPML_TYPE: song
  :OPML_F:   Frank Zappa - Don't Eat the Yellow Snow
  :END:
#+END_SRC

|
|
org-element--parse-elements
|
|

#+BEGIN_SRC emacs-lisp
(org-data
        (headline "My Great Playlist"
          (etc, snipped because printing this makes a huge mess)
#+END_SRC

|
|
magic-happens-here
|
|

#+BEGIN_SRC emacs-lisp
(outline
 ((text . "My Great Playlist"))
 (outline
  ((text . "The Cold Cold Ground.mp3")
   (type . "song")
   (f . "Tom Waits - The Cold Cold Ground")))
 (outline
  ((text . "Don't Eat the Yellow Snow.mp3")
   (type . "song")
   (f . "Frank Zappa - Don't Eat the Yellow Snow"))))
#+END_SRC

|
|
xml-print
|
|

#+BEGIN_SRC xml
<outline text="My Great Playlist">
    <outline text="The Cold Cold Ground.mp3" type="song" f="Tom Waits - The Cold Cold Ground"/>
    <outline text="Don't Eat the Yellow Snow.mp3" type="song" f="Frank Zappa - Don't Eat the Yellow Snow"/>
</outline>
#+END_SRC

It's the magic that will take some doing, though!

Eric

Re: the "right way" to build OMPL export and import

[Nicolas Goaziou]

Hello,

Eric Abrahamsen <eric@ericabrahamsen.net> writes:

> I'm not sure the general export engine is going to be of much use,
> since XML is so completely flexible, but you'll definitely want to
> build it on top of the internal parser.

It would be a bad idea not to use the export framework, unless you want
to reinvent the wheel (e.g., re-implementing skipping of :noexport:
tags).

> Luckily, the parser turns an org subtree into a parse tree, and the
> function `xml-print' turns a parse tree into XML. They're not quite the
> same parse tree, but I guess you'll want to do something like this:
>
>
> #+BEGIN_SRC org
>   ,* My Great Playlist
>   ,** The Cold Cold Ground.mp3
>   :PROPERTIES:
>   :OPML_TYPE: song
>   :OPML_F:   Tom Waits - The Cold Cold Ground
>   :END:
>   ,** Don't Eat the Yellow Snow.mp3
>   :PROPERTIES:
>   :OPML_TYPE: song
>   :OPML_F:   Frank Zappa - Don't Eat the Yellow Snow
>   :END:
> #+END_SRC
>
>
> |
> |
> org-element--parse-elements

Please use `org-element-parse-buffer' instead. As the two consecutive
hyphens suggest, this is an internal function.


Regards,

-- 
Nicolas Goaziou

Re: the "right way" to build OMPL export and import

[Eric Abrahamsen]

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

> Hello,
>
> Eric Abrahamsen <eric@ericabrahamsen.net> writes:
>
>> I'm not sure the general export engine is going to be of much use,
>> since XML is so completely flexible, but you'll definitely want to
>> build it on top of the internal parser.
>
> It would be a bad idea not to use the export framework, unless you want
> to reinvent the wheel (e.g., re-implementing skipping of :noexport:
> tags).
>
>> Luckily, the parser turns an org subtree into a parse tree, and the
>> function `xml-print' turns a parse tree into XML. They're not quite the
>> same parse tree, but I guess you'll want to do something like this:
>>
>>
>> #+BEGIN_SRC org
>>   ,* My Great Playlist
>>   ,** The Cold Cold Ground.mp3
>>   :PROPERTIES:
>>   :OPML_TYPE: song
>>   :OPML_F:   Tom Waits - The Cold Cold Ground
>>   :END:
>>   ,** Don't Eat the Yellow Snow.mp3
>>   :PROPERTIES:
>>   :OPML_TYPE: song
>>   :OPML_F:   Frank Zappa - Don't Eat the Yellow Snow
>>   :END:
>> #+END_SRC
>>
>>
>> |
>> |
>> org-element--parse-elements
>
> Please use `org-element-parse-buffer' instead. As the two consecutive
> hyphens suggest, this is an internal function.

I was hoping you'd jump in!

Would you suggest an export backend that only handles headlines (other
elements are a no-op)? I suppose you could just write org-opml-headline
to read properties and return XML chunks, and then you wouldn't have to
use `org-element-parse-buffer' at all.

E

Re: the "right way" to build OMPL export and import

[Nicolas Goaziou]

Eric Abrahamsen <eric@ericabrahamsen.net> writes:

> Would you suggest an export backend that only handles headlines (other
> elements are a no-op)? I suppose you could just write org-opml-headline
> to read properties and return XML chunks, and then you wouldn't have to
> use `org-element-parse-buffer' at all.

I don't know well OMPL format, but IIRC, it needs an inner-template
(which would handle <opml>, <head>, etc.), a headline transcoder, and
a couple of objects transcoders (e.g., for entities) in order to
properly export text attribute.

Anyway, you don't need to use `org-element-parse-buffer' at all.


Regards,

-- 
Nicolas Goaziou

Re: the "right way" to build OMPL export and import

[Eric Abrahamsen]

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

> Eric Abrahamsen <eric@ericabrahamsen.net> writes:
>
>> Would you suggest an export backend that only handles headlines (other
>> elements are a no-op)? I suppose you could just write org-opml-headline
>> to read properties and return XML chunks, and then you wouldn't have to
>> use `org-element-parse-buffer' at all.
>
> I don't know well OMPL format, but IIRC, it needs an inner-template
> (which would handle <opml>, <head>, etc.), a headline transcoder, and
> a couple of objects transcoders (e.g., for entities) in order to
> properly export text attribute.
>
> Anyway, you don't need to use `org-element-parse-buffer' at all.

Great, thanks for the tips. Sorry if I hijacked the thread a bit, anyway
should be useful to the OP...