Re: [xml-dev] How long before services sending/receiving XML mightneed r

I want to avoid details because they are always so limited in the context of language and framework. But if you try creating some XML with .NET libraries then simply changing from UTF 8 to UTF 16 you should realise how poorly these libraries work and how many ridiculous hoops you have to jump through to avoid memory leaks. It is simply a matter of curtailed investment, still stuck with original DOM-based processing. It forces people to use the xml serialisation libraries in ways never intended, just to allow use of StringBuilder so the character encoding can be specified as UTF 16, which, if the XML is at all dynamic involving more than merely a strongly typed document, results in memory leaks building up over time. Very bad. To try to avoid the serialise, the developer has to use XmlTextReader and convoluted code to try to get it to allow UTF 16 output with UTF 8 input. Not nice. You then get to see how immature these libraries are and how little investment has been made in getting them to work with each other and improving them with time. They are stuck in 2005.

On Sun, 14 Nov 2021 at 12:11, Norman Gray <norman.gray@glasgow.ac.uk> wrote:

Steve, hello.

On 14 Nov 2021, at 8:31, Stephen D Green wrote:

> Yet the challenges of creating fairly simple
> XML documents today, even with XML-era technology such as .NET, are getting
> worse because XML support is never updated.

Could you say a little bit more about this? I'm not aware of there being a challenge here, which makes me think I'm misunderstanding your whole point.

Different languages have different APIs for this, and while they're sometimes a bit annoying (apart from Racket's, which is lovely), I wouldn't call them a challenge. Python's API is sufficiently un-pretty that I use a home-made one (at about 50 lines of code), but that was mostly the product of procrastination, and a desire to use something a bit more Racket-ish. I remember Java's API being annoyingly fiddly, but no more than the rest of Java. And crucially, I don't see any of these being more fuss than learning an API to output JSON.

Are you thinking about problems at very large scale, or with relatively exotic XML? By that I mean XML involving PIs, DTDs, CDATA sections, and all that jazz, which I generally wouldn't put under the heading of 'simple XML documents.

XML input is certainly more of a fuss than a JSON reader, but that's simply because XML has a more intricate syntax than JSON. And I don't think anyone disagreeing that there are plenty of cases where XML would be an overcomplicated format for a simple serialisation problem.

> For example, just converting
> UTF-8 XML to UTF-16 requires conjuring tricks with serialisation which
> cause memory leaks, and the kinds of string buffer and stream conversions
> that would baffle any developer except an XML specialist.

Isn't that just iconv?

Changing encodings will always require a little bit of nous, which is avoided in JSON by the simple (wise) expedient of mandating a single encoding for all.

Best wishes,

Norman

--
Norman Gray : https://nxg.me.uk
SUPA School of Physics and Astronomy, University of Glasgow, UK