Hendrik Boom wrote on 6/27/20 8:33 AM:
But in section 4. Appendix there is one bit of pervasive confusion: you present several
differences, but do not make it clear which way the difference goes. When you say, for
example, "The SXML keyword symbols may be lowercase", do you mean that SXML
itseld allows this to be done to its keywords, or that it does not but that xexpr allows
its SXML keywords to be lower case?
Thank you. I didn't phrase that well. In section "Appendix:
SXML/xexp", that bulleted list is describing "SXML/xexp", relative to
canonical SXML.
That first bulletpoint is something on which I think SXML was
ambiguous. (Some Scheme readers or symbol tables forced or disregarded
case, but others thankfully didn't. Although, IIRC, Oleg's code was
consistent in how it used case, the ambiguity of the case of the symbols
in SXML presented portability problems when other people wrote code,
especially if they interpreted it differently, and exercised their
preferences, then you tried to combine their code. Many Scheme
programmers emphasized personal preference, and we can imagine that a
small language with powerful linguistic extension, and a convention of
writing one's own interpreter, might attract rugged individualists.)
"SXML/xexp" tried to mitigate that in a portable way, by saying both
all-uppercase and all-lowercase were supported, and that no other mixing
of case was permitted.
From this, and from the general drift of your sxml-intro, I surmise
that the intent is for Racket to become fully SXML compliant, and new
software should be written for SXML, not xexpr, if at all possible.
There's no policy that I know of.
I think switching would be better overall, but switching is a lot of
work. And, in a sense, there's less focus in practice on XML and HTML
than there used to be, so less reason than before to invest in
switching. I suspect any switch won't happen wholesale, but telling
people about the separate `sxml` package might result in some future
projects choosing to use SXML. I don't know how much activity future
projects will be.
When I first started with Scheme, I was actually lucky in my timing, in
avoiding fragmenting the XML/HTML representations even worse. The first
Scheme code I wrote was an HTML parser, and, initially, I made my own
obvious s-expression encoding of HTML, which turned out to be very
similar to Racket's `xexpr`. But I quickly saw Oleg's XML work, and so
reworked my code to emit SXML, so that the fancy XML tools could also be
used with real-world HTML. The switch to SXML was trivial for me then,
but the switch would've been hard for Racket (aka PLT Scheme), by the
time SXML became a de facto standard for the Scheme community.
Finally, I seem to remember that one of the tools mentioned somewhere for
handling xml turned out not to be findable. I don't know any more if it was
mentioned in your document or elsewhere, but it might be worth checking that
the ones you mention are still available.
Are you thinking of Jim Bender's `sxml-match`? I need to fix that dead
link (can't release a new version at the moment), probably to point to
the PLaneT package that the text mentions.
http://planet.racket-lang.org/display.ss?package=sxml-match.plt&owner=jim
--
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.
To view this discussion on the web visit
https://groups.google.com/d/msgid/racket-users/9fa1be59-64af-c3dd-9f3f-d49cf693a0d8%40neilvandyke.org.
