[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
Re: [xml-dev] How long before services sending/receiving XML might need replacement?
- From: Norman Gray <norman.gray@glasgow.ac.uk>
- To: Stephen D Green <stephengreenubl@gmail.com>
- Date: Sun, 14 Nov 2021 12:10:58 +0000
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
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]