4 ms·

Killing XML (it's my pleasure)

3 points by mqsiuser 12y ago

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?

bdfh42 12y ago
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.
- mqsiuser 12y ago
  > 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 ?!
CervezaPorFavor 12y ago
XSD seem good for several reasons: validation, contract, auto-complete and documentation.
- mqsiuser 12y ago
  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)
  - pestaa 12y ago
    Oh really? http://json-schema.org/ 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.
    - mqsiuser 12y ago
      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 :)
splawn 12y ago
Here is a good back and forth on s-expressions vs xml. http://c2.com/cgi/wiki?XmlIsaPoorCopyOfEssExpressions http://c2.com/cgi/wiki?XmlIsaPoorCopyOfEssExpressions
- mqsiuser 12y ago
  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
  - splawn 12y ago
    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.
_random_ 12y ago
There are no mainstream alternatives when you need a declarative, extensible mark-up. JSON doesn't fit this bill, unfortunately.
- mqsiuser 12y ago
  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?! ;)

3 points by mqsiuser 12y ago

bdfh42 12y ago

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.

mqsiuser 12y ago
> 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 ?!

CervezaPorFavor 12y ago

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

mqsiuser 12y ago
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)
- pestaa 12y ago
  Oh really? http://json-schema.org/ 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.
  - mqsiuser 12y ago
    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 :)

splawn 12y ago

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

mqsiuser 12y ago
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
- splawn 12y ago
  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.

_random_ 12y ago

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

mqsiuser 12y ago
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?! ;)