XML, Java, and the Future of the Web (1997)

https://www.xml.com/pub/a/w3j/s3.bosak.html

by mxschumacher • 5 years ago

43 94 5 years ago

xml.com

gjvc• 5 years ago

"This is a far cry from the systems that were built and proven during the 1970s and 1980s."

I wish the author had enumerated some examples here.

im3w1l2• 5 years ago

Seeing this here, I can't help but feel that there were some good stuff in the vision for the future of xml. I'm not saying we should bring back xml, but maybe a few of the ideas should be salvaged.

vbezhenar3• 5 years ago

Namespaces, schema.

Though I think that namespaces are pretty trivial to add to Json. At least in a primitive form. Just add key “namespace” to some object.

And there’re multiple efforts to make Json Schema. But so far most of APIs that I saw, do not use those.

brundolf• 5 years ago

GraphQL could almost be seen as an attempt to standardize on that

eyelidlessness4• 5 years ago

JSONSchema is alive and well, at least in OpenAPI.

lmm2• 5 years ago

Namespaces and schema were exactly what was wrong with XML.

jdeisenberg• 5 years ago

XML Schema, unfortunately, won out over RelaxNG (https://relaxng.org/) which has a much more solid mathematical basis and (in my opinion) is much more direct and simple than XML Schema.

rjsw• 5 years ago

Has XML gone away ? I'm working on a project that uses it.

agumonkey• 5 years ago

not gone away, just not the revolution on top of which everything computing will be based on

tdhz77• 5 years ago

I’m working with it. It’s not really that advantageous for this project. US code is outputted in XML and I’m having to write a of code to find certain attributes to render on a page. Seems like it will break very easily on xml updates.

Devasta3• 5 years ago

Its temporarily retreated on the web, but its still used heavily in finance.

The SWIFT network is looking to migrate to XML in the next few years, and to my knowledge FedWire is looking to do the same.

im3w1l2• 5 years ago

Well we certainly didn't build an xml semantic web rendered to xhtml using xslt stylesheets. And xmlhttprequest is mostly used to fetch json. And I don't think xml is used that much for new protocols or fileformats anymore either.

stickfigure2• 5 years ago

I'm pretty comfortable saying we should bring back XML. Not for RPC-ish protocols; JSON is a much better fit. But certainly every single place that YAML is used.

eezing• 5 years ago

And then we tried to use it.

jpgvm• 5 years ago

Looking back at XHTML I am reminded again and again that the best technical solution often loses out.

Instead we have HTML5 which contains nothing that couldn't have been easily expressed in XHTML but have none of it's strictness that would have enabled much simpler and better browser implementations.

The arguments against XHTML amounted to "but wahh it should still work even if the syntax is wrong". Thing is none of the major proponents of XHTML were advocating for exterminating the existing doctypes and their associated quirks modes. People could continue to use that but XHTML would be there, ready for the advent of non-shit programming to hit the web.

People are starting to come around the ideas of strictness in programming languages again with Typescript and co rapidly gaining in popularity. It's just such a massive shame the entire Web community forced this massive wheel-reinventing cycle on us for no damn reason, completely ignoring the lessons learnt -literally everywhere- else.

beachy• 5 years ago

It's the cycle of innovation. Like a cat retching up a hair ball. It repeats over and over, until finally something is coughed up. Except in technology it takes years instead of seconds.

Just like MongoDB gaining mindshare - because webscale - only for people to realise those relationships and structured types were actually quite good at keeping your data clean.

stickfigure2• 5 years ago

HN folks whine about browser monoculture but it was this decision (and thousands more like it, but this one is pretty big) that meant you cannot have a simple browser implementation. Any 2nd year CS student could write an X(HT)ML parser. Writing an HTML5 parser requires FAANG resources.

jazzyjackson2• 5 years ago

Could you elaborate at all on what makes HTML5 so much more difficult to parse?

cxr3• 5 years ago

Writing an HTML5 parser requires FAANG resources.

No it doesn't. The HTML5 parsing algorithm is well-defined, and parsing it according to the spec is not an order of magnitude more difficult than properly handling XML according to its spec. What makes browsers difficult does not come from the part that involves ingesting the initial response payload and building it into a tree in a spec-compliant way—what makes things difficult is all the other stuff involved with creating and maintaining a browser.

KronisLV3• 5 years ago

You know, as someone stuck using XHTML within the Java ecosystem for web apps, i'd say that it's reasonably easy and nice to work with. However, i'd also like to suggest that custom tags, at least when implemented in the ways that are popular in those particular technologies (JSF/PrimeFaces) are bad both from a usability and maintainability perspective - it took many years for React to come around and make components easy to create and utilize. XHTML with the semantics of React would be way better.

That said, i'm also stuck in the middle of migrating older versions of frameworks (Spring) to newer ones (Spring Boot) and it's proving to be extremely cumbersome and feels like it'll be impossible to get right without spending multiple months on the migration. Most of the older technologies are considered "dead" nowadays for a reason, though at the same time i agree that they can hold a certain wisdom.

Cthulhu_• 5 years ago

XHTML with the semantics of React would be way better.

Isn't Web Components an attempt at something like that?

vintermann• 5 years ago

"Actually pretty decent ideas, but completely botched on implementation elsewhere" is a story that we've heard many times in the Java world... I remember the OSGI folks elation as Eclipse turned to OSGI from their custom plug in system, turn to dismay as they saw how it was actually used.

vbezhenar3• 5 years ago

XHTML is supported, you can use it, major browsers did not deprecate it. And forcing it through developers throat - I'm not sure if it's a wise decision. In the end developers would just stay in HTML 4.

Thiez2• 5 years ago

I'm not so sure they would stay in HTML4. Currently HTTPS is being "forced" by having features that are only available over HTTPS (such as, but not limited to, HTTP/2 and HTTP/3) and this has been fairly helpful. XHTML adoption could have been encouraged using similar tactics, and most developers would have gone along.

zozbot2342• 5 years ago

XHTML5 is a thing, it is still there. You can use it in all modern browsers (no IE) and it adds support for XML namespaces to the HTML5 featureset.

BurnGpuBurn• 5 years ago

I remember working a lot with XML a decade ago. XML was large and clumsy and had problems like undefinable ordering of elements for instance. And I haven't actually encountered a single parser library that did not have some strange issue which made it behave outside the spec. Not to mention editors that happily show "<tag\>" while in reality the file reads "<tag></tag>". Good luck debugging the parser with that one. My bad experience with the XML standard is probably the reason why I never bothered with XHTML. Sure, cool idea, but XML, so meh.

bryanrasmussen• 5 years ago

Not to mention editors that happily show "<tag\>" while in reality the file reads "<tag></tag>"

I believe you mean tag/ as every parse I know of would choke on tag\.

if it is tag/ the XML spec says there is no difference between these two scenarios, thus most tools and libraries will serialize as tag/ (I say most because maybe somebody silly somewhere did differently)

NackerHughes• 5 years ago

undefinable ordering of elements

Could you elaborate a bit more on that? By my understanding, order of elements in XML is significant, and child elements are kept in an ordered list.

oofbey2• 5 years ago

XML was a dumpster fire from day one. It burned hot for a while but thankfully has all but faded away.

tablespoon• 5 years ago

XML was a dumpster fire from day one. It burned hot for a while but thankfully has all but faded away.

Thankfully we got rid of it and replaced it with data formats that got rid of the anti-features like comments.

oofbey2• 5 years ago

Douglas Crockford explicitly refused to allow comments in JSON because he saw people using them to faithfully encode XML metadata in them. So actually you could blame XML for that too.

Now YAML is mostly replacing JSON in places where you want human readability, and JSON is only used for data exchange.

narrator2• 5 years ago

Everything XML wanted to be, JSON did better. Xml validation and namespaces were kind of half way there solutions that just made things more complex than they needed to be.

murukesh_s• 5 years ago

half way there solutions

Care to explain more? I though they were over engineered compared to bare bones JSON. For e.g. JSON schema is still catching up to XML schema and the ecosystem it had back then (XSLT, XPATH) etc.

XML is of course heavy weight, but we should compare YAML against XML, not JSON - JSON doesn't have for e.g. comments, CDATA etc.

narrator2• 5 years ago

DTD validation and XML schema were overly complicated solutions that didn't cover a lot of validation cases and should have just been implemented via libraries in the target language instead of making developers maintain yet another half-baked DSL. In the end, everything is JavaScript was the better way.

thaumasiotes6• 5 years ago

- XML starts with a version designator.

- JSON allows arbitrary integers to be represented as numeric values. That works fine on its own, but it causes serious problems if you trust the name of the format, "JavaScript Object Notation". You can't do that in JavaScript objects.

- JSON has no comments. Or version designators.

The big problems in XML are named closing tags and the weird distinction between children and attributes. JSON did those things better, by not having them at all. But XML is a long, long way from "like JSON, but worse in every way".

(Another big problem in XML-considered-as-an-ecosystem is the prevalence of people who want to deal with it by using regular expressions. As far as the technology goes, this is a non-issue -- it's a problem with the user, not the technology. But I do have to admit that the JSON equivalent appears to be loading the data into a parser that doesn't work, as opposed to loading the data into a non-parser that doesn't work.)

lmm2• 5 years ago

- XML starts with a version designator.

Which has proven to have zero real-world use case.

- JSON allows arbitrary integers to be represented as numeric values. That works fine on its own, but it causes serious problems if you trust the name of the format, "JavaScript Object Notation". You can't do that in JavaScript objects.

That's not a problem with JSON, that's a problem with standardized JavaScript. I believe JSON was named before there was an official standard that required JavaScript implementations to be terrible.

- JSON has no comments. Or version designators.

Indeed, and it's all the better for it.

bonzini5• 5 years ago

JSON allows arbitrary integers to be represented as numeric values

It doesn't, numbers not in the range of a double have implementation-defined behavior.

GoblinSlayer2• 5 years ago

JSON allows arbitrary integers to be represented as numeric values.

JSON doesn't mandate the use of binary numbers, parsers can keep number literals as strings and let the user choose whatever binary storage.

The big problems in XML are named closing tags and the weird distinction between children and attributes. JSON did those things better, by not having them at all.

JSON has this design freedom too: should a collection of values be an object or an array?

bruce343434• 5 years ago

JSON allows arbitrary integers to be represented as numeric values.

What are the practical problems one runs into due to this mechanic? Isn't that just, any number literal scheme in any language ever?

nfoz• 5 years ago

How do you like to express nested <b>marked-up <i>text</i> in JSON</b>?

bonzini5• 5 years ago

{'style': 'bold', 'children': [ 'marked-up ', {'style': 'italic', 'children': [ 'text' ]}, ' in JSON']}

In fact, Pandoc's internal format is exportable in JSON

eyelidlessness4• 5 years ago

XHTML was my preference, even had some of the semantics I wish weren’t lost (<h/>). It’s not a hill I want to die on, but I do very much wish there was a successful push for its strictness.

Mikhail_Edoshin2• 5 years ago

What's that <h/>?

eyelidlessness4• 5 years ago

It’s h1-n but its hierarchy was determined by semantic parent structure rather than its own declaration. IIRC you could use similar semantics to the existing h-tags within a given hierarchy with an attribute. And I’m pretty sure this lived through some of the early HTML5 process, but ultimately didn’t make it through.

nivertech3• 5 years ago

Going back to the late 90s, I think these are the only interesting bets taken by the industry:

- Ericsson's Erlang/OTP

- Sun's "The Network is the Computer" and "Utility Computing", IoT - "Jini" (Internet-connected toasters;), and non-PC devices - smartphones, set-top boxes, smart cards - JavaCard is still popular.

- Bell Labs/Lucent's Plan 9 and Inferno OS (neither is gained adoption)

- Semantic Web (which never took off).

IMO, XML and Enterprise Java were regression, but so is REST, JSON and dynamic scripting languages. The most recent example is GoLang.

EDIT: the XML itself is a good family of specs (especially XSD, XPath and XSLT), the problem was with abusing XML by forcing it onto everything: from configuration to logs to over-the-wire format like in XMPP. I remember IBM even sold XML Accelerator appliances ;)

pjmlp6• 5 years ago

Altought one could say that "The Network is the Computer" kind of won out, in the jungle of RPC protocols that we use nowadays.

Part of Inferno OS lives on what Go took from Limbo, and Go still isn't capable of using dynamic libraries like Limbo did.

nivertech3• 5 years ago

If I'm not mistaken the only part of Limbo that survived in Go is named typed channels.

In Limbo/Inferno one could either download the module and run the code locally or execute the code remotely without downloading it.

cies• 5 years ago

IMO, XML and Enterprise Java were regression

From what? (especially XML as im not even sure what E-Java means)

I think (as you also mention yourself) that XML is quite good at some things (it's schema based, can mix schemas, has namespaces, etc). Just (as you mention as well) it was overused at some point.

Given we agree so much: what is it that XML was a regression from?

JSON is a regression from XML wrt schemas/strictness; but then it was very low overhead (which was needed as is it gain momentum used in places where the client (JS browser app) and the server (serverside of said browser app) are both maintained by the same organization).

nivertech3• 5 years ago

XML abuse was a regression from using ASN.1 or custom binary protocols, which were a much better fit for the hardware at the day.

IMO Java was a dumbed-down C++ for Enterprises and an attempt by Sun to escape Wintel monopoly. We could've had a much better mainstream programming languages now than Java or C#. Better PLs means higher bar for software quality.

cratermoon• 5 years ago

XML suffered from the verbosity of having both open and closing tags and the weird uncertainty around attributes vs. child tags, but the real problems came from consultant-driven programming wanting to put XML everywhere and use if for everything. Ant & Maven. SAML. XML for configuration and DI frameworks. *ML everything. Did you know there was a thing called VoxML[1]? Basically XML for phone menus (remember those? Press 1 for English, Press 2 for ... Press 9 to hear these options again).

SAX was the hammer applied to every problem.

1. http://xml.coverpages.org/voxML.html

occoder• 5 years ago

XML is the finest example of cargo cult engineering.

"The Web was a huge success, there must be a reason. Oh I know, it must have been HTML. We need more of that, and bigger, extensible! Behold, XML!"

I remember shaking my head in wonder during the height of the XML hype. What were all those supposedly very smart people thinking?

To me, HTML was already a huge mistake, the Web succeeded in spite, not because of it. What could you do in HTML/XML that you couldn't in s-expression, only simpler, more readable, and more writable? How many man-years have we collectively wasted having to read/write/generate/process/validate/... the mess that is HTML/XML, as opposed to a simpler, more sensible format such as s-expression?

jazzyjackson2• 5 years ago

The current CSS effort provides a style mechanism well suited to the relatively low-level demands of HTML but incapable of supporting the greatly expanded range of rendering techniques made possible by extensible structured markup. The counterpart to XML is a stylesheet programming language that is...Published in April, 1996, DSSSL is the stylesheet language of the future for XML documents.

I started building a custom JSON representation of HTML templates with embedded functions for importing fragments and generating markup etc and soon realized I was re-inventing XSLT [0] but kept going anyway. I haven't really seen another template language that can translate one DOM tree to another. It seems like XSLT is the eventual implementation of DSSSL in TFA, I'd be curious if anyone can speak to why it never caught on.

[0] https://en.wikipedia.org/wiki/XSLT

christkv• 5 years ago

Having used XSLT professionally in the early 2000s I think it was that most developers found it hard to reason about due to the recursive nature of the language.

Devasta3• 5 years ago

Absolutely, so many tried to go about it procedurally and fought the language rather than adapt to its way of thinking.

Once you understand apply-templates though, it becomes much easier.

vbezhenar3• 5 years ago

CDuce is a sane XSLT alternative. Although it's mostly research project, AFAIK.

bjoli• 5 years ago

For scheme there is SXML which has SXSLT, SSAX and SXPath. Translating between xml and SXML is trivial, and SXML is just an S-expression representation of XML, meaning it is in the canonical list form.

Working with lists in scheme is pretty great. I stopped using any other xml tools for my own projects.

Mikhail_Edoshin2• 5 years ago

XML is language-oriented, it's like a typical programming notation but without a parsing step (or, rather, with a standard parsing step). It's a very unusual thing in this aspect and, I guess, this is the source of all the misunderstanding.

E.g. it's very successful in things like layout/UI description, which is naturally language-like. And not that successful in data exchange applications, which is not language-like. (To exchange data with a language-like medium is like integrating programs by constructing their command lines; possible, but way less convenient than by using a library.)

If we are to compare it with something it would be Loglan or Lojban, not JSON. The difference is that it's a working and widely used Loglan. Something like this will have to be central to navigate a vast sea of documents, which is what Web was supposed to be. Web has changed quite a bit, but those documents didn't go anywhere and the problem is as acute as ever. More acute, I would say; in 1997 there wasn't that much content there.

higon• 5 years ago

Idea of XML being superior to anything was the plague nearly everyone at the time caught. Evangelists would be the chosen one or so they thought. But they turned out to be a bunch of con men chasing easy fame. Having once been vaccinated with dynamic programming languages and coding-by-convention, who will ever go back there?

Oh... typescript... you...!!!

Devasta3• 5 years ago

Custom elements, CSS Namespaces, client side templating, all things that we had decades ago and were just dumped. Abandoning XML and XHTML is and continues to be the webs biggest mistake. People can pretend there were good reasons to stick with HTML but having "On Error Resume Next" baked into your language was a known bad practice even then...

I am optimistic for XMLs future though, as the rise of stuff like TypeScript and Rust shows that people do appreciate strict languages nowadays, and WASM means that modern versions of XSLT can be utilized on browsers even if the browser vendors cannot be bothered implementing them.

usrusr• 5 years ago

It's so easy to look back at XML with ridicule, sitting on the hill of json pragmatism success. But take a moment to consider what we had before XML. Yes, XML was awesome. Back then you'd consider yourself lucky working with data available in a format that had implementations across multiple operating systems.

BiteCode_dev2• 5 years ago

I loved xHTML, but it failed for a very simple reason: people designing it were working on a DSL to structure a document. But the vast majority of users were actually trying to make things look pretty.

Most websites are currently blobs of div. Why ? Because the idea of a web page being mainly a document completely missed the part were artists fiddling with messy code would produce things that customers would like better.

It's the same reason we currently see giant images on home pages and 10mo static assets to load. Because in the end, the best technical decision doesn't win. The one that gives the result the customers end up preferring wins.

If you have 3 hours to get a design done, you have the choice between making it look great, or having a clean semantic and maintainable markup, you will have to drop one. And the market will select according to the result.

Thiez2• 5 years ago

If you have 3 hours to get a design done, you have the choice between making it look great, or having a clean semantic and maintainable markup, you will have to drop one. And the market will select according to the result.

Depends on whether accessibility is a priority. Depending on where you live it may be mandatory by law, for larger organizations.

BiteCode_dev2• 5 years ago

Nah, what will happen is that accessibility will be dropped 9 times out of 10. And one day, many years from that decision, they will receive a notification from the state, stating the site is not accessible. And then the site will be made that way. Maybe.

The situation were a website is made accessible from the start is such a tiny rare occasion it cannot be used to explain why xhtml failed.

pjmlp6• 5 years ago

Another reason for div blobs is that HTML is not a language to describe GUI applications rather documents.

So one ends up with a soup of divs, made pretty with CSS and then replicate the behaviour of a beatiful dropdown fully in JavaScript, ignoring the browser builtin infrastructure.

Naturally because this breaks down in every browser, it is then extended with hacks for every corner case.

XML, Java, and the Future of the Web (1997)

Related Stories