4 ms·
There are a quite a few problems with XML: * Few who were coming up with a format/DTD/schema understood the differentiation between placing value data in attri
by devmonk 16y ago
There are a quite a few problems with XML:
* Few who were coming up with a format/DTD/schema understood the differentiation between placing value data in attribute values vs. element values.
* Element values would sometimes contain whitespace prefix and suffix due to formatting which caused problems with those values in the beginning.
* The optional XML declaration attribute didn't even fit in with the rest of the spirit of the format.
* The wealth of greater-than, less-than, slashes and quotes in the data was unnecessary, and converting from text to compressed format and back barely ever took off.
* The format allowed having one element partially within the scope of another <like><this></like></this> unlike bracket scope notation that would never have had such ambiguitity.
I could go on and on.
Transformation? Michael Kay may have been the man with the bible in the early 2000s, but I think everyone realized by the mid 2000s that XSLT and related XML transformations were a huge seemingly bottomless pit of wasted effort. What is needed was code, and people keep trying to make XSLT handle logic. Think of what those same people could have written in the same time using Java, Ruby, Python, PhP, Javascript. It is mind-boggling the amount of waste that XML and related formats have caused.
Moving bits around? Bits are moving around no matter what format you use. Why not use something that saves typing, and doesn't waste everyone's time?
All that said. XML is out there. I still do SOAP, WSDL, etc. I still mess with SAX and DOM in Java. I write XML services in Ruby and consume them. It is inescapable.
JSON doesn't yet cover all of the bases, but at least it is on a better track. Once people really think about the problems with XML- only then can we really evolve in the way we write and use unformatted human-readable data documents.
- davewiner 16y agoThe only reason I added JSON is so that people could use it in places that you can't use XML. I wish the designers of JavaScript had been less keen on reinventing things. Yet another format we all have to support. Sigh.
- devmonk 16y agoWhile I agree that it is frustrating to worry about offering things in different formats, JSON is not terrible, and it is much more compact while still being human readable. It is only natural that something easier to read and type than XML would suffer a period of overlap with XML, etc.
- zdw 16y agoNobody manually enters all the tags for XML/HTML/SGML - you ought to be using an editor that supports some combination of tag shortcuts, tag completion, Zen Coding, or some other schema-aware entry method. I'd go nuts too if I had to enter all the tags by hand, if my left index/ring fingers didn't fall off first.
- devmonk 16y agoThe point is that XML, like any format, is not perfect. If you get the chance to transition to using JSON or another well-used less flawed format in the future, why not? Some clarifications: * XML's End tags/elements are visual noise and cause additional unnecessary data to need to be stored. * Greater thans, less thans, and slashes are more visual noise and less intuitive and readable than the brackets, commas, and colons in JSON. * The fact that you can have values as attributes or as element values has caused confusion since the beginning. Attributes allow 1:1, but schemas can describe 1:1 as element values even though the same element could otherwise appear multiple times and be 1:*. Why should you be wasting time having to decide which to use when you are trying to define a format? Few bust on XML because they think that would be lunacy, since it is so prevalent. If everyone uses it, it must be better right?