Re: [xml-dev] It's too late to improve XML ... lessons learned?

A huge benefit, brought by XML, was that with Unicode, it allowed developers an equal playing field, providing a way out for legacy developers stuck with dying platforms, who could now work alongside developers using newer technologies, and so lose the stigma and have a future. It also provided a way to pivot away from legacy platforms previously locked in to legacy character sets such as EBCDIC (apologies to anyone still using it). Anyone could now send data to Unix, Mainframes, Windows, iOS, in the same way, so these recipients and the senders alike could switch platform without breaking the communication. It promoted communication, opening new horizons in e-Commerce, which we cemented with the likes of WS*, ebXML, UBL and PEPPOL; e-Government too. This paved the way for many, many new kinds of service, and SaaS and eventually of course the Cloud. If JSON become predominant, it was XML and Unicode that ploughed the field in which JSON was sown. It created the incentive for all platforms to support the same character sets and technologies, which took computer history to the next level in which it became a ubiquitous medium for more productive public and private services. Those who have profited should be ready to pay something back, reinvesting in the societies which made them rich.

On Thu, 6 Jan 2022 at 05:24, Tim Bray <tbray@textuality.com> wrote:

I've come to think that, in the long-distance rear-view, one of XML's biggest legacies was moving Unicode from a fringe thing to a place where there was a huge contingent of developers who'd been forced to think about it.

On Wed., Jan. 5, 2022, 9:06 p.m. John Cowan, <johnwcowan@gmail.com> wrote:

On Wed, Jan 5, 2022 at 7:27 AM Stephen D Green <stephengreenubl@gmail.com> wrote:
Of course they love having emojis. And non Western countries need the character sets.

So does everyone that trades with them. $EMPLOYER, which provides legal document analysis, is a U.S. company, but it deals with documents not just in English and Spanish but French, Portuguese, Italian, Greek, Japanese and Chines Chinese. WIthout Unicoda that would be impossible.

On Wed, 5 Jan 2022 at 12:26, Stephen D Green <stephengreenubl@gmail.com> wrote:
Not kidding. Look at ASCII. Look at SQL. To end users these suffice for many things. They did need utf to allow communication between machines with different architectures but nobody would care beyond that. A perfect ASCI or perfected SQL would not be top of their wish list.

On Wed, 5 Jan 2022 at 10:53, Rick Jelliffe <rjelliffe@allette.com.au> wrote:

On Wed, Jan 5, 2022 at 10:55 AM Stephen D Green <stephengreenubl@gmail.com> wrote:
"Now that XML exists, there is no driver for anything better. JSON was a happy accident so that does not count."

Your kidding, right?

I don't think we reached a steady state of technology in 1997, and nothing has changed in the subsequent 25 years that could possibly make it worthwhile to revisit the goals and engineering decisions of XML? No Big Data? No 3G/4G/5G? No GPUs, cheap SSDs, SSE/AVX, etc? No ubiquitous Unicode? No HTML 5? No cloud computing? No ubiquity of XML-in-ZIP formats? No Git? No failure of Web Services? No ubiquitous availability of interpreted languages with eval() functions? No REDIS? No XSD and its disappointments? Etc. etc.

And how can JSON not count? If something does not have drivers for its success, surely it would not have succeeded?

It seems that many Big Data systems read in a dialect of JSON, with one JSON "file" per line. They scan for the appropriate line then read in the record. How is that not an example of the kind of non-ephemeral data that we thought XML should be good at? XML at W3C stopped responding to drivers; diverted first by giantism of the data-binding crowd then by the dwarfism of the sugar-free crowd.

(What JSON showed was that the driver was for a header-free markup language with richer delimiters that allowed direct specification of datatypes through syntax, trivially converted to conventional datatypes and structures: not richer but more complex, nor simpler but less rich, but rich and simple: more expressive syntax.)

A standard can breed or it can go into palliative care.

Rick

--
----
Stephen D Green

--
----
Stephen D Green