Killing XML (it's my pleasure) | Hacker News Reader

Killing XML (it's my pleasure)

3 pointsmqsiuser11 comments

It is not that the technology on top of XML failed.

XML itself failed miserably:

1. Namespaces (and 4 ways to use them) & Namespace-Prefixes

2. Element-repetition "</element>"

3. Attributes -> just not enough added value

4. Angle Brackets (Markup) "<", ">"

5. xsd (just not needed)

6. All on top: xslt, xpath, WS-x, SOAP

If you subtract the bad, then there is nothing left...

For what I do ((fast) message transformation) you require a (message) tree (and nothing else). That would be:

"XML-Elements only"... but still with angle brackets & repetition (of the element name): Both bad ;)

What am I missing / am I missing anything ?

Can we consider XML to only be a choice in rare circumstances?

View on HN

OK I agree, XSD was just a way for pedants to be a pain.

But, any form of structured communication that works for humans (and this is a mark-up language that is supposed to work in the human as well as machine spheres) has to include a degree of apparent redundancy that actually applies clarity - well at least avoids ambiguity.

My preference is always JSON but XML is cool when it flows and has available tools.

> but XML is cool when it flows and has available tools

That's just excuses ("having tools") for failing (on an aspect)

If flows ? :-)

It's been a great contribution thank you TBL! Thank you. (Let's move on)

> for pedants to be a pain

:-) (strange) computer scientists "we are interested in formal completeness" WHAT ?!

XSD seem good for several reasons: validation, contract, auto-complete and documentation.

JSON seems to be fine without (a "schema language")

Why is that ?

I know the answer: No-one ever requested it

O.k. xsd uses XML and I just made the CASE AGAINST XML (itself)

You may reduce XML to "elements only", but then still...

Angle brackets "<" & ">" (markup) are BAD.

Curly braces "{" & "}" are GOOD...

... because they just get used differently:

< and > are markup (from HTML (SGML)) and enclose elements/tags/identifier. { and } are from set theory (math) and enclose data... a set (of things)

Oh really? http://json-schema.org/

The industry seems to be going in circles. 15 years from now the new kids will hate JSON and hate JSON schema and all the complex JSON toolchain, and so they will reinvent the wheel.

who knows of it, who uses it ?

There may be like circles (ofc... the circle of live ;), but not the same (different things are different :)

Here is a good back and forth on s-expressions vs xml. http://c2.com/cgi/wiki?XmlIsaPoorCopyOfEssExpressions

That is so old (2003). It is so much (am I supposed to read it?) (what is LISP ;).

And it is so wrong:

"XML is simple to parse": If I (I am a parser... or parser writer) hit the end of something then it is just the end: So it is "}" or the "EOF"-special-character

Again: Subtract everything (from XML), then you have "(XML-)elements only" (so "valid" xml):

What is (still) wrong then:

- Element repetition "</element>" (that won't be fast and compact):

Not fast for a parser to process and not compact to submit over the wire

- Use of more than one character to start (and end) a block (a block structure): < and > and everything in between :)

It is so super easy, nothing more

Yes, I'm sure this debate is as old as XML itself. The last edit on that page was in 2013, btw. I agree with you, XML is overkill 99% of the time and I usually don't like working with it. Fortunately JSON seems to be taking over in a lot of areas. I just posted this link because I think simple sexps could do the job just as well as anything else for most situations.

There are no mainstream alternatives when you need a declarative, extensible mark-up. JSON doesn't fit this bill, unfortunately.

Hey, I am doing the "case against XML" here.

On JSON: I'd require others to comment, whether it is declarative or extensible (enough). Whether this is required (or not) for the use cases we have.

Mark-up?! ;)

Reply on news.ycombinator.com