|
[XML-DEV Mailing List Archive Home]
[By Thread]
[By Date]
[Recent Entries]
[Reply To This Message]
Re: The Goals of XML at 25, and the one thing that XML now nee
- From: Marcus Reichardt <u123724@gmail.com>
- To: Rick Jelliffe <rjelliffe@allette.com.au>
- Date: Tue, 20 Jul 2021 11:30:23 +0200
 With respect, I don't share that negative outlook wrt markup languages. It might not be the vehicle it used to be around 2000 to bring business, investors, and prestigious academic publications, if that's what you mean. But then XML never had a good case for most of the uses it was proposed for during that time, such as service payloads, serialization of component models, config languages, and even programming languages (with exceptions, of course).
The point Mukul brought up is a good one (in a negative sense), since a Maven pom.xml doesn't make use of mixed content, arguably an indicator for SGML/XML adequateness. A pom.xml doesn't even allow general entities, relying on its own import/derivation mechanism instead. Thus it's clearly incidental use of XML, and I believe the Maven developers said as much when they were venturing into allowing alternative forms of serializing a POM ten or more years ago, which however never came to life since the Maven ecosystem basically stagnated since (and thankfully, the Maven devs stopped refactoring when they figured they couldn't get the kind of manpower behind it). Another case in point in the Java ecosystem is the demise of XML configs in Spring and Jakarta EE (née JEE née J2EE) in favor of annotations.
The only use case for SGML/XML is, and always has been text document representation. And as shown by the reactions on HN is as relevant as it ever was,(once again, apologies Rick; didn't expect this to make it to the front page). There was another post yesterday advocating for the use of PDFs (!) on the Web, the point being self-contained docs rather than PDF per se. And there's very much a sense that the Web has gone too far, with browsers ceasing and so-called web standards only pulling up the ladder such that no browser can be developed from scratch ever again due to sheer complexity.
XML won't go away anytime soon; there's simply no multiparty ecosystem, academic discourse/canon, or other broad consent around anymore that could deliver standards such as POSIX, SQL, and SGML/XML.
And no, XML wasn't meeting its goals well for the Web; if it were, we don't need to have this discussion and browsers would use XHTML. That's no problem, though, as XML's big beautiful sister SGML fills the gap with support for what's actually needed for authoring on the Web, such as support for parsing HTML, idiomatic shortforms, markdown, typesafe/HTML-aware templating, and all the other things left out from the XML subset of SGML. XML will continue, however, to be a long-term archival and robust and widely supported backend format, and as the format an SGML processor produces as canonical output markup.
In fact, now is the time to position XML/SGML as the language for an offline/document-oriented/less-invasive web.
Am 20.07.2021 um 08:44 schrieb Rick Jelliffe <rjelliffe@allette.com.au>:
Let the dead bury the dead!
Another adage is that anything that does not grow dies. I think XML has reached that stage. It continues to be fine for what it does, but it is not now a technology that opens new doors or promotes new efficiencies. Which is just not a necessary or desirable fate.
XML is now at a much worse stage than where SGML was in 1995: standardized, adopted, stable, fit for purpose, but essentially solving the problems of the 1980s in a 1970s kind of way. And with a weeny technology (HTML) that could not possibly be considered a competitor or alternative because of its features, but sure was being adopted in that spirit.
XML was a really great subset of the SGML idea for Web backends, meeting its goals well. It is possible to make different offspring from the SGML wellspring that meet other goals. IMHO, parallel-parseability is meets a constant demand and is a good goal, and inplace parsing is a low-hanging fruit on this.
By parallel-parseability I suppose I mean non-modal or random-access parsing: that you should be able start at any point in a document and figure out whether you are in tagging or data by parsing forward until the next milestone delimiter (i.e. > or ;) which then tells you what you started in. When get this by not allowing modes, or allowing delimiter strings to serve double duty. So you can sick any number of threads onto different locations in the document and they will be able make sense of it without needing to know what went on before.
Cheers Rick
Cheers Rick
.....
(Now, I am not saying that for data JSON is always the best, nor that XML doesn't have other features that may make it best to provide feeds in both JSON and XML, nor that if you currently have a good XML infrastructure you should rip it up and not take advantage of it.)
You may not be saying that but that's the sentiment behind JSON for enterprise integration, we killed XML or JSON ate it's lunch. So NIEM, FPML and god knows who else end up having to put out a JSON spec even though JSON is not capable of representing the semantics in those data models.
|
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
|
PURCHASE STYLUS STUDIO ONLINE TODAY!
Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!
Download The World's Best XML IDE!
Accelerate XML development with our award-winning XML IDE - Download a free trial today!
Subscribe in XML format
| RSS 2.0 |
 |
| Atom 0.3 |
 |
| |
Stylus Studio has published XML-DEV in RSS and ATOM formats,
enabling users to easily subcribe to the list from their preferred news reader application.
|
Stylus Studio Sponsored Links are added links designed to provide related and additional information to the visitors of this website.
they were not included by the author in the initial post. To view the content without the Sponsor Links please
click here.
|
|
Cart
