Subject: [bug#57963] Almost plain SXML serializer

From: Andrew Tropin <[email-masked]>
Date: Wed, 12 Oct 2022 11:07:33 +0400

On 2022-10-11 06:21, Liliana Marie Prikler wrote:

> Am Dienstag, dem 11.10.2022 um 12:54 +0900 schrieb Taiju HIGASHI:
>> We can specify invalid value such as (list "foo" '(foo bar) 123).
> It will be sanitized before that.
>
>> > Also, making multi-type fields is debatable, but isn't great IMO.
>> 
>> I see. If we had to choose one or the other, I would prefer the
>> string-type field.
> Prefer sexp-type.
>

Current (v5) extra-config has a list type.  This list can contain strings
and nested lists, string elements are for raw XML, and list
elements are for SXML.

This is done I guess to support following use case:

--8<---------------cut here---------------start------------->8---
(list "<tag>Already existing XML copied from existing .xml file, which
we don't want to rewrite to SXML.</tag>"
      '((tag (@ (attr1 "value1")
                (attr2 "value2"))
             (nested "Part of the configuration defined with SXML")
             (empty)))
      "<another-tag>Maybe some other part of raw XML</another-tag>")
--8<---------------cut here---------------end--------------->8---

This way we can combine SXML with already existing raw XML.

Am I right?

>> > If serialization would support G-exps, we could write
>> > 
>> > (list #~"RAW_XML_HERE")
>> > 
>> > or even something like this:
>> > 
>> > (list #~(READ-THE-WHOLE-FILE #$(local-file "our-old.xml")))
>> 
>> Does it mean that the specification does not allow it now? Or does it
>> mean that it is not possible with my implementation?
> I think your serialize would have to unpack the G-Expressions.  You can
> test that with some example configs of your own.
>
>> > 
> Cheers

-- 
Best regards,
Andrew Tropin