guix-patches
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[bug#57963] Almost plain SXML serializer


From: Andrew Tropin
Subject: [bug#57963] Almost plain SXML serializer
Date: Thu, 13 Oct 2022 07:51:35 +0400

On 2022-10-12 20:23, Liliana Marie Prikler wrote:

> Am Mittwoch, dem 12.10.2022 um 17:03 +0400 schrieb Andrew Tropin:
>> On 2022-10-12 20:42, Taiju HIGASHI wrote:
>> 
>> > 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.
>> > 
>> 
>> Ok, that means we can cover this use case, but at the same time have
>> more functionality, clarity and consistency.
>> 
>> We can make extra-config to be SXML only (with G-exps support), this
>> way we will achieve not only the same functionality, but will get
>> more advanced features like referencing files/directiories in the
>> /gnu/store or generating parts of configuration using full-fledged
>> scheme (the simpliest example is just reading the content of the
>> existing file-like object or using format to generate "raw XML" and
>> insert it in arbitrary place of SXML tree).
>> 
>> --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")
>>              ,#~(format #f "    <nested-tag>~a</nested-tag>"
>> #$variable)
>>              (fontdirs
>>               (dirs ,(file-append font-iosevka "/share/fonts")))
>>              (empty)))
>>       #~(call-with-input-file #$(local-file "old.xml") get-string-
>> all)
>>       #~"<another-tag>Maybe some other part of raw XML</another-
>> tag>")
>> --8<---------------cut here---------------end--------------->8---
>> 
>> Liliana, Ludo what do you think?
> I think the mockup implementation is a little unclear. 

The file generated from definition above should look like:
--8<---------------cut here---------------start------------->8---
<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>Text node</nested>
    <nested-tag>variable value here</nested-tag>
  <fontdirs>
    <dirs>
      
/gnu/store/w2wvg2229lj3qba0r44pmd786mkllvjl-font-iosevka-15.2.0/share/fonts
    </dirs>
  </fontdirs>
  <empty/>
</tag>
<!-- the literal content of old.xml file here -->
<another-tag>Maybe some other part of raw XML</another-tag>
--8<---------------cut here---------------end--------------->8---

Hope it helps, let me know if you want me to rephrase or clarify
something.

> Do you mean that G-Expressions should imply a string that is to be
> parsed?  Because note that gexp->sexp exists and you could likewise
> #~(sxml->xml #$some- file-in-the-store) imho.

Not sure what you mean. Can you elaborate, please?

-- 
Best regards,
Andrew Tropin

Attachment: signature.asc
Description: PGP signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]