[bug#57963] Almost plain SXML serializer

[Taiju HIGASHI]

Andrew Tropin <andrew@trop.in> writes:

> 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:
>
> (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>")
>
> This way we can combine SXML with already existing raw XML.
>
> Am I right?

You're right.  The current implementation allows XML string and SXML
list in the list.  Also, it can mix those.

>>> > 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

Thanks,
-- 
Taiju