Greg Hendershott wrote on 07/28/2015 04:30 PM:
Imagine conversion functions `xexpr->sxml` and `sxml->xexpr`.
Would implementing them be any easier than unifying xexprs and sxml
(or is it really just the same problem)?
Yes, I think those procedures would be easy to implement in such a way
that they worked well. Seems like a reasonable convenience, given the
situation.
Details...
Conversion is mostly just a simple recursive tree/DAG traversal and some
consing. And you have to decide how to handle XML namespaces (see how
SSAX handles them). Fortunately, you don't have to get into DTDs in
either representation.
Allocations-wise, you can generally share the XML CDATA strings verbatim
between the two representations, without copying, so the allocations
probably won't be too bad.
It's probably not very expensive unless, of course, your XML is so huge
and pair-heavy that a copy pushes you into a hard GC or (shudder!)
swap. (Or if you have a lot of this conversion going on, like in
high-volume server transactions, and it's a significant part of the
time/space/garbage overhead; but if you're doing that, then you are
already solving harder problems than doing these conversions, and you
probably wouldn't need these procedures in the first place.)
For `sxml->xexpr`, note that it might not be obvious that SXML element
attributes can actually appear interspersed with element contents.
You'll have to accumulate element attributes separate from element
contents, and cons attributes onto the front as you finish constructing
a result element.
In the documentation, you'd want to quickly note that the procedures
exist for "historical reasons" (or "interoperation"), because otherwise
smart people might immediately wonder why the procedures exist at all.
And maybe also tell people which representation they should be using by
default, since I think that might be the next question on people's minds.
Neil V.
--
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.
