Re: [Chicken-users] ssax/sxml and lowdown transforms

[Markus Espenhain]

> On 06 Jun 2015, at 20:06, Moritz Heidkamp <address@hidden> wrote:
> 
> Hi Markus,
> 
> On  6 June 2015 18:12 CEST, Markus Espenhain <address@hidden> wrote:
> 
>> I’m still new to chicken and scheme so please bear with me :)
> 
> no need to apologize, this list is exactly the right place for questions
> like that :-) Welcome to CHICKEN!
> 
> 
>> I had some trouble to mange some sxml transforms
>> 
>> The first - what would a transform rule look like to transform
>> 
>>    (foo ((bar) (baz)))
>> 
>> into
>> 
>>    ((bar) (baz))
> 
> I suggest to do it this way:
> 
>    (pre-post-order* '(foo ((bar) (baz)))
>                      `((foo . ,(lambda (_ x) (car x)))
>                        ,@alist-conv-rules*))
> 
> Check Peter's tutorial on SXML transformations to understand how it
> works: http://www.more-magic.net/docs/scheme/sxslt.pdf -- note that it
> uses `pre-post-order' rather than `pre-post-order*' which has a slightly
> different API. It's generally recommended to use the latter at least
> with CHICKEN due to its argument list length limitation.

Aaaah sorry my fault. The example was a bad one. I have to explain a bit more …

I had managed to embed scheme (or better SXML nodes) into a markdown document, 
currently (mis)using 'code' and 'verbatim'. For my current use case this is ok 
but from there comes the need for custom inline and block hooks.

Within a verbatim block one can place many of these scheme snippets without a 
enclosing one and that’s ok, since every of these commands later describes a 
block of it’s own - for example

   (item "item one"
          "description")
   (item "item two")

is a equivalent of writing

`(item "item one" "description")`

`(item "item two")`

In the first transform of the returned document form (markdown->sxml* text), I 
transform this

   (verbatim ("(item \"item one\")\n"
              "      \"description\")\n"
              "(item \"item two\")\n"))

into something like this

   (foo (item "item one" "description") (item "item two"))

After that I have another rule set which transforms the document into 
something, wich I can pass to medea json->string. That  sounds probably a bit 
strange but at the point, where I realised that this it is possible, to 
transform a SXML document with a simple ruleset into something totally 
different I found this pretty cool :)

The JSON document is then used to create a PDF, which is generated outside 
chicken. Anyway, the JSON document structure is given and the mentioned items 
block, for example is transformed into something like this

   (foo ((table …)
         (style . #("item-table")))
        ((table …)
         (style . #("item-table"))))

I had managed everything (also the #\space issue) the only thing I had to get 
rid of was this enclosing block of the original verbatim block and move the 
items in to the first level. You mentioned it somewhere below that this is not 
valid SXML and I think that this is somehow the problem here too.

So my question/example in the first mail should be - how to transform

   ((foo ((bar)) ((baz)))) 

into

   (((bar)) ((baz)))

Which is obviously not valid SXML and I think not possible at all since the 
transform handler had to return two trees which must then sequentially added to 
the parent.

For now I do a manually tree walk, as I already did for the spaces, to 
'flatten' these verbatim/foo blocks into first level elements.

> 
> 
>> lowdown returns all spaces in a extra spaces list - for example:
>> 
>>    (paragraph "this" (#\space) "is" (#\space #\space) "text")
>> 
>> How would one match these 'spaces' nodes and transform them into a single 
>> space instead
>> 
>>    (#\space) -> " "
>>    (#\space #\space) -> " "
>> 
>> or alternatively
>> 
>>    (#\space \#space) -> "  "
> 
> In case you are unfamiliar with the #\space thing: these are just space
> character objects. The reason for these being characters rather than
> strings is that the parser works on the character level and it just
> passes these through as it finds them in the input. It would require an
> extra conversion step to turn them into a string. This is generally not
> a problem as most of the SXML tools cope with characters just fine even
> though this is not part of the spec. There was some discussion recently
> to change Lowdown to emit proper SXML. I'm open to this, it's just not a
> pressing need of my own and I didn't find the spare time to do it,
> yet. You could look into this and send me a patch if you like!
> 
> Anyway, if you want to turn those characters into strings in your own
> code for now, you'd have to do a custom tree walk. Alternatively, use an
> SXML transformation rule for each node type which can contain text and
> do the conversion there. My question is: Why do you want to do this in
> the first place? :-)

As mentioned above - I had to turn the markdown into a PDF document using this 
intermediate JSON which uses a structure like this for text

   ((text . #("This" " " "is" " " "text")))

If i leave the space nodes untouched I end up with 

   ((text . #("This" (#\space) "is" (#\space) "text")))

or when defining *text* and make #\space into a string with this

   ((text . #("This" (" ") "is" (" ") "text")))

but this is something I can’t pass to medea json->string

I did the latter you mentioned and did the conversion for every node type that 
can contain text. For example

   `((paragraph . ,(lambda (_ tree) (list (text . (text-vector tree)))))
     …)

text-vector also combines continuous strings into one … works so far :)

> 
> 
>> ps @the-lowdown-authors - It would be cool if a lowdown 'user' could
>> register custom inline hooks (and also block hooks!). I saw the
>> lowdown-extra, which creates two inline hooks but the inline-hook
>> parameter is not exported … or at least I did not know how to import +
>> call inline-hook :)
> 
> This is not part of the public API, yet, I only added enough to make
> `lowdown-extra' possible. But you are very welcome to give it a try :-)
> Just `(use lowdown-lolevel)' in your module to import
> `inline-hook'. Check `lowdown-extra.scm' for how to use it. A
> `block-hook' would definitely be nice to have, too, I agree. This is
> just another thing which has not come up so far.

Hm, I thought I also tried (use lowdown-lolevel) but yes - if I use (use 
lowdown-lolevel) I can access and call inline-hook  

Thanks for your reply, that did really helped :)
Markus

> 
> Hope that helps!
> Moritz