Re: [racket-users] sxml vs xexpr frustrations

[Neil Van Dyke]

Philip McGrath wrote on 2/1/19 5:14 PM:
I will say an advantage of the xexpr code is that it's written in 
(reasonably) modern Racket rather than portable Scheme, which I've 
found somewhat easier to understand when I've wanted to read the 
sources, though the sxml code is extensively commented.


Yes, IIRC, Oleg's code of that era was mostly RnRS portable, and a few 
bits of implementation-specific (Chez?), and his "standard prologue" 
(which made sense at the time, but, thankfully, package systems help 
make more-reusable packages without that).  (IIRC, I did the first 
packaging of Oleg's SSAX for Racket (nee PLT Scheme) v103 or v200, and 
then Kirill Lisovsky et al. packaged various Oleg code for many Scheme 
variants, and then John Clements did a heavier wrangling of Oleg's code 
for modern Racket.)


My relatively small contributions are mostly old portable Scheme code 
that I wish I could rethink and reimplement.  (IIRC, the permissive HTML 
parser you mention was the very first Scheme code I ever wrote, to start 
to build out Scheme as a platform for research like Web-inhabiting 
autonomous agents and Semantic Web, and I did some naive things while 
blindly guessing at performance costs (e.g., parsing lookahead).  Today, 
I'm more comfortable on performance, and I'm also not coding to a 
portable subset of RnRS and minimal SRFIs. Though I'd probably write the 
next one in RnRS and judicious use of Racket extensions, so one might 
still see the occasional precise named-`let` in some places where a 
`for`-something might've been shoehorned in. :)


 For example, if you care about the source syntax, you want to 
distinguish  blocks and numeric entity references from 
naked textual data, but for higher-level purposes I want to treat all 
of those things as Racket strings


The SXML faction is not totally unresponsive to the desire for 
conveniences. :) 
https://docs.racket-lang.org/html-writing/#%28part._script_.Element%29


There were also a few SXML extensions that, last I looked at it, I was 
backing out, more towards canonical SXML (for example, the character 
entity notation made more sense before widespread Unicode, and when some 
Schemes were even had character case-insensitive symbols): 
https://docs.racket-lang.org/sxml-intro/#%28part._sxml-xexp%29


The new representation I'd hypothetically do would be different than 
either xexpr or SXML.


Anyway, it sounds like those people who have being doing XML and HTML in 
Racket (or at least, are still on the list?) have been able to get their 
work done, despite the unfortunate historical accident that led to the 
two main representations?


I couldn't say whether or how much opportunity we've missed over the 
years, with the divided effort, and potentially lost network effects 
(e.g., a couple people are impressed by what's available, uses it, 
contributes back a layered library or framework that someone else uses, 
repeat exponentially).  And exactly what library support we could use 
today is different from back then, so we don't want to just do now what 
we wish we'd done back then.


--
You received this message because you are subscribed to the Google Groups "Racket 
Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [racket-users] sxml vs xexpr frustrations

[Philip McGrath]

I've written a fair amount of XML processing code in Racket (sometimes one
has to work with external standards and tools), and I thought I'd jump in
to say that I've been content with xexpr. I don't mean that as a criticism
of sxml, though: I happened to have learned xexpr first, and I've never
taken the time to do a detailed assessment of the pros and cons of each.

I will say an advantage of the xexpr code is that it's written in
(reasonably) modern Racket rather than portable Scheme, which I've found
somewhat easier to understand when I've wanted to read the sources, though
the sxml code is extensively commented.

In terms of interoperability, perhaps this is obvious (and it certainly
feels a little ridiculous), but, the few times that I've needed an
sxml-based tool (Neil's html-parsing
 comes to mind), I've just used
XML as the intermediate format, either in strings or through a Racket-level
pipe.

I think a challenge in this area in general is that different applications
want different things out of an XML representation. For example, if you
care about the source syntax, you want to distinguish  blocks
and numeric entity references from naked textual data, but for higher-level
purposes I want to treat all of those things as Racket strings—or, per
Jay's comment, it's a great convenience when writing to be able to omit
empty attribute lists, but it adds another case to handle when manipulating
x-expressions. I've generally addressed these kinds of issues by adding
some sort of normalization pass so that I only have to handle a restricted
subset of the x-expression grammar.

-Philip

On Fri, Feb 1, 2019 at 9:09 AM Leo Uino  wrote:

> On 2019/02/01 3:24, Matthew Butterick wrote:
> > Yes, it's true that the Racket XML library doesn't support namespaces.
>
> Indeed - although I hacked up a solution for that for another project[1]:
>
> http://docs.racket-lang.org/xml-ns/index.html
>
> I agree with the sentiment regarding the rest of the XML stack. One of
> these days I'll finish off XSD support and have done with it...
>
>
> Leo
>
> [1] With apologies for blowing my own trumpet
>
> --
> You received this message because you are subscribed to the Google Groups
> "Racket Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to racket-users+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [racket-users] sxml vs xexpr frustrations

[Leo Uino]

On 2019/02/01 3:24, Matthew Butterick wrote:

Yes, it's true that the Racket XML library doesn't support namespaces.


Indeed - although I hacked up a solution for that for another project[1]:

http://docs.racket-lang.org/xml-ns/index.html

I agree with the sentiment regarding the rest of the XML stack. One of 
these days I'll finish off XSD support and have done with it...



Leo

[1] With apologies for blowing my own trumpet

--
You received this message because you are subscribed to the Google Groups "Racket 
Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [racket-users] sxml vs xexpr frustrations

[Hendrik Boom]

On Thu, Jan 31, 2019 at 12:39:19PM -0500, Christopher Lemmer Webber wrote:
> Is xexprs really maintained either?  At any rate, not all software needs
> very active maintenance; sxml seems to be fairly stable.  Maybe you
> disagree. :)
> 
> At any rate, I don't think xexprs support namespaces, which sxml has
> tooling for, which is one important thing.

There was once a paper published calle "The essence of XML" that emphasized 
that what made XML different from all other ways of linearizing a tree 
structure was that it handled namespaces properly.

So if you don't want to have namespaces -- which make it possible to embed 
disparate algebras into the same tree -- you might as well use 
S-expressions.

-- hendrik

> 
> Matthew Butterick writes:
> 
> > I (ab)use xexprs for Pollen because they're used in the Racket web
> > server, and because at the time, SXML seemed largely abandoned — no
> > traffic on its mailing list [1] and today, even Oleg's SXML page is a
> > 404. [2]
> >
> > I wouldn't try to pry SXML from anyone's fingers. But dragging around
> > open-source software abandoned by its owner tends to incite conditions
> > of madness. (Insert your favorite 80s typesetting system here.)
> >
> > [1] https://sourceforge.net/p/ssax/mailman/ssax-sxml/
> > [2] http://pobox.com/~oleg/ftp/Scheme/SXML.html
> >
> >  On Jan 30, 2019, at 10:27 AM, Christopher Lemmer Webber 
> >  wrote:
> >
> >  IMO, it makes more sense to have sxml be the "right" one, since it has
> >  wider user outside of just Racket, and there are some much nicer tools
> >  available for it:
> >
> >   https://docs.racket-lang.org/sxml-intro/index.html#%28part._.Tools%29
> >
> >  (That, and I find the @ property syntax a bit easier to follow, but that
> >  barely matters.)
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Racket Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to racket-users+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

-- 
You received this message because you are subscribed to the Google Groups 
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [racket-users] sxml vs xexpr frustrations

[Matthew Butterick]

Stability is narrower than maintainability, which includes the idea of "can the 
software be improved to suit current needs". 

For instance: I'd be willing to look into adding SXML conversion functions to 
my `txexpr` package if you'd find them useful. But when I try to read Oleg's 
spec for SXML, it's gone. 

Yes, it's true that the Racket XML library doesn't support namespaces. I 
imagine part of the issue is that XML belongs to a stack (incl SAX, XPath, 
XSLT) that was never much loved to begin with, and once you've done it the 
Racket Way, feels even more like dragging rocks uphill. On Jupiter.

To be fair, I use xexprs mostly to generate HTML, not XML, so these 
shortcomings aren't bothersome. Those who cannot forgo namespaces will stick 
with SXML.


> On Jan 31, 2019, at 9:39 AM, Christopher Lemmer Webber 
>  wrote:
> 
> Is xexprs really maintained either?  At any rate, not all software needs
> very active maintenance; sxml seems to be fairly stable.  Maybe you
> disagree. :)
> 
> At any rate, I don't think xexprs support namespaces, which sxml has
> tooling for, which is one important thing.

-- 
You received this message because you are subscribed to the Google Groups 
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [racket-users] sxml vs xexpr frustrations

[Stephen De Gabrielle]

Hi,

> [2] http://pobox.com/~oleg/ftp/Scheme/SXML.html
 moved to http://okmij.org/ftp/Scheme/SXML.html

Kind regards,
Stephen

On Thu, 31 Jan 2019 at 17:39, Christopher Lemmer Webber <
cweb...@dustycloud.org> wrote:

> Is xexprs really maintained either?  At any rate, not all software needs
> very active maintenance; sxml seems to be fairly stable.  Maybe you
> disagree. :)
>
> At any rate, I don't think xexprs support namespaces, which sxml has
> tooling for, which is one important thing.
>
> Matthew Butterick writes:
>
> > I (ab)use xexprs for Pollen because they're used in the Racket web
> > server, and because at the time, SXML seemed largely abandoned — no
> > traffic on its mailing list [1] and today, even Oleg's SXML page is a
> > 404. [2]
> >
> > I wouldn't try to pry SXML from anyone's fingers. But dragging around
> > open-source software abandoned by its owner tends to incite conditions
> > of madness. (Insert your favorite 80s typesetting system here.)
> >
> > [1] https://sourceforge.net/p/ssax/mailman/ssax-sxml/
> > [2] http://pobox.com/~oleg/ftp/Scheme/SXML.html
> >
> >  On Jan 30, 2019, at 10:27 AM, Christopher Lemmer Webber <
> cweb...@dustycloud.org> wrote:
> >
> >  IMO, it makes more sense to have sxml be the "right" one, since it has
> >  wider user outside of just Racket, and there are some much nicer tools
> >  available for it:
> >
> >   https://docs.racket-lang.org/sxml-intro/index.html#%28part._.Tools%29
> >
> >  (That, and I find the @ property syntax a bit easier to follow, but that
> >  barely matters.)
>
> --
> You received this message because you are subscribed to the Google Groups
> "Racket Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to racket-users+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>
-- 


-- 
You received this message because you are subscribed to the Google Groups 
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [racket-users] sxml vs xexpr frustrations

[Christopher Lemmer Webber]

Is xexprs really maintained either?  At any rate, not all software needs
very active maintenance; sxml seems to be fairly stable.  Maybe you
disagree. :)

At any rate, I don't think xexprs support namespaces, which sxml has
tooling for, which is one important thing.

Matthew Butterick writes:

> I (ab)use xexprs for Pollen because they're used in the Racket web
> server, and because at the time, SXML seemed largely abandoned — no
> traffic on its mailing list [1] and today, even Oleg's SXML page is a
> 404. [2]
>
> I wouldn't try to pry SXML from anyone's fingers. But dragging around
> open-source software abandoned by its owner tends to incite conditions
> of madness. (Insert your favorite 80s typesetting system here.)
>
> [1] https://sourceforge.net/p/ssax/mailman/ssax-sxml/
> [2] http://pobox.com/~oleg/ftp/Scheme/SXML.html
>
>  On Jan 30, 2019, at 10:27 AM, Christopher Lemmer Webber 
>  wrote:
>
>  IMO, it makes more sense to have sxml be the "right" one, since it has
>  wider user outside of just Racket, and there are some much nicer tools
>  available for it:
>
>   https://docs.racket-lang.org/sxml-intro/index.html#%28part._.Tools%29
>
>  (That, and I find the @ property syntax a bit easier to follow, but that
>  barely matters.)

-- 
You received this message because you are subscribed to the Google Groups 
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [racket-users] sxml vs xexpr frustrations

[Matthew Butterick]

I (ab)use xexprs for Pollen because they're used in the Racket web server, and 
because at the time, SXML seemed largely abandoned — no traffic on its mailing 
list [1] and today, even Oleg's SXML page is a 404. [2] 

I wouldn't try to pry SXML from anyone's fingers. But dragging around 
open-source software abandoned by its owner tends to incite conditions of 
madness. (Insert your favorite 80s typesetting system here.)

[1] https://sourceforge.net/p/ssax/mailman/ssax-sxml/
[2] http://pobox.com/~oleg/ftp/Scheme/SXML.html

> On Jan 30, 2019, at 10:27 AM, Christopher Lemmer Webber 
>  wrote:
> 
> IMO, it makes more sense to have sxml be the "right" one, since it has
> wider user outside of just Racket, and there are some much nicer tools
> available for it:
> 
>  https://docs.racket-lang.org/sxml-intro/index.html#%28part._.Tools%29 
> 
> 
> (That, and I find the @ property syntax a bit easier to follow, but that
> barely matters.)

-- 
You received this message because you are subscribed to the Google Groups 
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [racket-users] sxml vs xexpr frustrations

[Jay McCarthy]

On Thu, Jan 31, 2019 at 1:56 AM Konrad Hinsen
 wrote:
> I actually migrated code from SXML to xexpr in order to be able to use
> Pollen.

For me, it feels like SXML is really optimized for consuming XML and
xexpr is really optimized for producing it.

Jay

-- 
-=[ Jay McCarthy   http://jeapostrophe.github.io]=-
-=[ Associate ProfessorPLT @ CS @ UMass Lowell ]=-
-=[ Moses 1:33: And worlds without number have I created; ]=-

-- 
You received this message because you are subscribed to the Google Groups 
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [racket-users] sxml vs xexpr frustrations

[Konrad Hinsen]

Am 30.01.19 um 19:27 schrieb Christopher Lemmer Webber:


One very frustrating thing for me is the inconsistency between which
sexp xml representation is the "right" one, sxml or xexpr.  Different
tools support different things, and thus don't interoperate when they
easily could have.


Sounds... familiar.


IMO, it makes more sense to have sxml be the "right" one, since it has
wider user outside of just Racket, and there are some much nicer tools
available for it:


On the xexpr side, there are some very nice tools as well, in particular 
Matthew Butterick's Pollen:


https://docs.racket-lang.org/pollen/

and its low-level foundation txexpr:

https://docs.racket-lang.org/txexpr/index.html

I actually migrated code from SXML to xexpr in order to be able to use 
Pollen.


Konrad.

--
You received this message because you are subscribed to the Google Groups "Racket 
Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [racket-users] sxml vs xexpr frustrations

[Neil Van Dyke]

Christopher Lemmer Webber wrote on 1/30/19 3:59 PM:

Yes, the xexprs and SXML stuff is mostly very old (perhaps most of it from so 
far back that Racket even had its own little Web browser),

This one? https://docs.racket-lang.org/browser/index.html


Yes, that looks like it.  Regarding using it, of course you understand 
the difference between modern CSS and DOM, and Mosaic-era (or early 
Netscape Navigator) HTML, *and* you'd also want to sanity-check the 
security of the implementation, since I don't recall that being looked 
at in ages.


The two security things that come to mind to look at are the Racket eval 
feature, and exactly how the browser overall was implemented (e.g., make 
sure it doesn't use old crusty bits of C or C++ code, such as from an 
old wxWidgets).  Much lower-priority, you could also look at limiting 
its resource consumption.  Even if you control all content, injection 
happens.  (It could be that Racket's old Windows-like Help viewer is a 
very rare old Web browser not littered with serious vulnerabilities, but 
that's something to check.)


--
You received this message because you are subscribed to the Google Groups "Racket 
Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [racket-users] sxml vs xexpr frustrations

[Christopher Lemmer Webber]

Neil Van Dyke writes:

> 'John Clements' via Racket Users wrote on 1/30/19 1:46 PM:
>> Fundamentally, I think that what you’re proposing is sensible … and probably 
>> a lot of work that’s not currently at the top of anyone’s list.  :)
>
> Yes, the xexprs and SXML stuff is mostly very old (perhaps most of it
> from so far back that Racket even had its own little Web browser),

This one?

  https://docs.racket-lang.org/browser/index.html

Or is there another one I ought to know of? :)
Believe it or not, I may have good reason to make use of some of that
code, in my upcoming work...

  https://dustycloud.org/misc/mmose.pdf

-- 
You received this message because you are subscribed to the Google Groups 
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [racket-users] sxml vs xexpr frustrations

[Neil Van Dyke]

'John Clements' via Racket Users wrote on 1/30/19 1:46 PM:

Fundamentally, I think that what you’re proposing is sensible … and probably a 
lot of work that’s not currently at the top of anyone’s list.  :)


Yes, the xexprs and SXML stuff is mostly very old (perhaps most of it 
from so far back that Racket even had its own little Web browser), 
though most of the code has held up pretty well despite its age, but I'm 
not aware of much recent development.  (Held up well, thanks to John 
heroically preserving Oleg's code in the current Racket package system 
-- the biggest bit of bitrot was perhaps due to it not being written for 
a package system and doc system.)


The sparse recent development might be partly due to practitioners 
largely shifting away from HTML and XML, to JS-based frameworks and JSON.


There's also perhaps some "solved problem", such as when Oleg took a 
close look at XML, made his excellent parser, published about what he 
learned, and then moved on to other SXML/XML aspects, and to other areas.


That said, I speculate that there might be new boost of interest in 
HTML in Racket, if Racket gets a WASM backend, perhaps through the 
Chez work, and someone invests in pushing what that can do.


For now, I occasionally resist the urge to make a new representation 
(probably involving a mix of SXML and Racket syntax objects, and 
possibly also structs), and write new tools for it.  I've also wanted to 
do a few neat things with URI/URL, taking advantage of current Racket 
features, and based on what I learned with two earlier URI libraries in 
Scheme.  And to build upon my template work, and to do frameworky 
stuff.  Realistically, all that would have to be motivated and funded by 
paying work/research, like how some solid engineering work on Racket has 
and continues to be funded by goals of CS/PL systems research and CS 
education.



On Jan 30, 2019, at 10:27 AM, Christopher Lemmer Webber 
 wrote:

I wish the Racket community could collectively make a decision and "deprecate" 
one of them.


In case it comes up in discussion: one alternative to deprecating one of 
them in favor of the other won't work.  I previously tried to make a 
compromise unified representation, but it just didn't want to work 
without sacrificing the arbitrary nesting of SXML, which is one of 
SXML's performance strengths (for efficient splicing of potentially 
large chunks of SXML during transformation, especially now that Racket 
pairs are immutable).  I also tried to add splicing operators to the 
unified representation, then decided that Oleg had the more elegant idea 
from the start.


As a different approach to bridging xexpr and SXML worlds, I also 
started to try to make my SXML-ish template stuff also work with the 
Racket Web Server, but that work (along with my book and such) got 
interrupted in the middle of performance optimizing: 
https://www.neilvandyke.org/racket/rws-html-template/#%28part._.Known_.Issues%29


What I suspect will happen is that we'll continue to have our efforts 
divided between the  xexpr and SXML worlds until the Chosen One foretold 
by the prophets is born, to do all the PL work and human 
leadership needed to unite the two peoples.


BTW, to someone not very familiar with the XML and HTML stuff in Racket, 
I don't want to overstate the impression of a problem. There's a good 
chance that you'd just develop in one world, and find that the available 
libraries for that world do what you need.  I think it's only painful 
when you don't realize there's multiple worlds, and you take a while to 
realize that the library you're looking at is for a different world; or 
when your world happens to be missing functionality you need that the 
other world has.


--
You received this message because you are subscribed to the Google Groups "Racket 
Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [racket-users] sxml vs xexpr frustrations

['John Clements' via Racket Users]

You probably already know this, but this is basically a case of parallel 
evolution. The sxml tools come ultimately from Oleg Kiselyov, and I believe 
he’s the one who formulated the data definition. Many people have worked with 
him on this, including many people on this mailing list. I think it’s fair to 
say that xexprs come originally from Paul Graunke and Matthias, although many 
many many people here have worked on infrastructure related to xexprs. 

Fundamentally, I think that what you’re proposing is sensible … and probably a 
lot of work that’s not currently at the top of anyone’s list.  :)

John


> On Jan 30, 2019, at 10:27 AM, Christopher Lemmer Webber 
>  wrote:
> 
> One very frustrating thing for me is the inconsistency between which
> sexp xml representation is the "right" one, sxml or xexpr.  Different
> tools support different things, and thus don't interoperate when they
> easily could have.  I wish the Racket community could collectively make
> a decision and "deprecate" one of them.
> 
> IMO, it makes more sense to have sxml be the "right" one, since it has
> wider user outside of just Racket, and there are some much nicer tools
> available for it:
> 
>  https://docs.racket-lang.org/sxml-intro/index.html#%28part._.Tools%29
> 
> (That, and I find the @ property syntax a bit easier to follow, but that
> barely matters.)
> 
> Possibly opening a can of bikeshed,
> - Chris
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Racket Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to racket-users+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.



-- 
You received this message because you are subscribed to the Google Groups 
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[racket-users] sxml vs xexpr frustrations

[Christopher Lemmer Webber]

One very frustrating thing for me is the inconsistency between which
sexp xml representation is the "right" one, sxml or xexpr.  Different
tools support different things, and thus don't interoperate when they
easily could have.  I wish the Racket community could collectively make
a decision and "deprecate" one of them.

IMO, it makes more sense to have sxml be the "right" one, since it has
wider user outside of just Racket, and there are some much nicer tools
available for it:

  https://docs.racket-lang.org/sxml-intro/index.html#%28part._.Tools%29

(That, and I find the @ property syntax a bit easier to follow, but that
barely matters.)

Possibly opening a can of bikeshed,
 - Chris

-- 
You received this message because you are subscribed to the Google Groups 
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.