Comment by personZ | Hacker News Reader

Comment by personZ | Hacker News Reader

Parent Full thread

designed for editing text documents

This sort of argument has never held water, and it constantly perplexes me that it gets a pass in tech discussions. Even if we accept the dubious assertion that it was "designed" for editing text documents, the origins of some invention say literally nothing about its utility for a purpose.

Further, as complex as XML may be, comparing the robust, rich, diverse ecosystem of XML support with the amateur hour, barely credible JSON world is quite a contrast. JSON doesn't even have a date type (and everyone seems to roll their own). It lacks any sort of robust validation or transformation system: XML schemas are really one of XML's greatest features, and the nascent, mostly broken similes in JSON world don't compare.

JSON versus XML is a lot like NoSQL versus RDBMS -- the former is easier to pitch because its complete absence of a wide set of functionality seems like it makes implementations easier, when really it just pushes the complexity down the road.

I like XML for structured data. I also like XSL for self-documenting format to format conversion (or display). However I am going to respectfully disagree with you about XML schemas, they suck...

XML schemas don't "understand" XML the language, and as a result you cannot use schemas unless you're using XML wrongly. For example, in XML:

     <myroot> 
     	<thing>
     		<name>Robot</name>
     		<size>15</size>
     	</thing>
     	<person>
     		<name>John Smith</name>
     		<id>12345</id>
     	</person> 
     </myroot>

And:

     <myroot>
     	<person>
     		<name>John Smith</name>
     		<id>12345</id>
     	</person> 
     	<thing>
     		<name>Robot</name>
     		<size>15</size>
     	</thing>
     </myroot>

These two XML documents produce identical DOM and or XPaths. The fact that person and thing are inverted in the second example is irrelevant, but now try to write a schema definition which supports either thing/person or person/thing ordering.

It is possible to do with just one node switch in the above example, but convoluted. As you add more and more nodes the definition becomes unmanageable, imagine 10+ nodes on the same "level" but they can be ordered randomly, and are all required (and your schema needs to check they exist).

XML schema sucks, really sucks, when you use XML correctly and ignore node order. So if you choose to use a schema you're then forced to also require everything in an exacting order which can be problematic when XML is automatically generated from dozens of different systems or people.

XML schema sucked so bad we wrote our own replacement in Java. It just generates an XML DOM tree (via the standard libraries), then it parses your "schema" file which is just a list of XPaths with either a required, optional, or excluded flag. It is like 20 lines of code and it is better than XML Schema language.

XML schema sucks, really sucks, when you use XML correctly and ignore node order.

How is ignoring node order "correct" (and on the flip side, how is demanding an order using it "wrongly")? In many XML parser implementations, node order is reflected in the resulting DOM. Yes, a schema lets you demand that nodes come in a specific order, and this is a complete non-problem, generally -- the whole point of schemas is that they very tightly define the format, and source systems abide by it, even if that means they have to alter the generating order to be compliant.

As someone not intimately familiar with xml wouldn't xs:all do what you need? It provides unordered but required.

In theory yes. In practice absolutely no. The examples are oversimplified, and when you start using xs:all or xs:choice you quickly start running into inheritance issues (e.g. the top level node is optional, but when it exists child-XYZ are mandatory, and when you mix child optional and child mandatory things get "strange").

I spent a few days trying to get a schema working with our format. I had it working well enough with a specific node ordering, but when I tried to get it working with an order-agnostic set it would all break down around you.

That's when I threw out two full days of work and replaced it with a Java class I spent about an hour writing and testing. Working flawlessly ever since.

No idea about "XML Schema", but it's not the only schema language and Relax NG "interleave" should do what you want.

http://relaxng.org/spec-20011203.html#IDA2Z0R

As far as I understand this is a limitation of the underlying processing model (tree automata and such, although I'm not an expert). That is I suspect it would be equally hard to describe such an unordered collection of required elements using a context-free grammar. (On the other hand Relax NG seems to handle it nonetheless.)

With JSON you use a programming language to transform your data. You also use a programming language to validate your data. Validating and transforming data are some of the most basic capabilities of all general-purpose programming languages, and reinventing these facilities badly in a not-exactly-programming-language like XSLT or XML Schema is a waste of time.

This is same as saying that one shouldn't use parser generators or even describe the grammar of a language in Backus-Naur form. Any language is usually very well equipped with tools to read strings and BNF is absolutely not a programming language. Is it a waste of time?

If you validate a couple of document formats, then maybe, but if you need to validate many different formats on a regular basis you'll soon want to split your program into 1) a language that describes the rules and 2) an interpreter that takes such a description and validates a document against it. DTD, XML Schema, and Relax NG are just such tools.

> XML schemas are really one of XML's greatest features

So great that you get to choose between the schema system that's horribly complex (XML Schema) and the schema system that no one uses (DTDs).

> JSON versus XML is a lot like NoSQL versus RDBMS -- the former is easier to pitch because its complete absence of a wide set of functionality seems like it makes implementations easier, when really it just pushes the complexity down the road.

XML is like CORBA: a complicated mess whose proponents seem genuinely unaware that it's possible to achieve the same goals in a much simpler way (like Protocol Buffers).

There is nothing complex about xml schema. It is so profoundly simple, the tools so well worn and proven, that anyone who pronounces difficulty with it is probably in the wrong field.

And the notion that I must be unaware of protocol buffers (which has utterly nothing to do with the JSON vs xml conversation, but I suppose is the bigger brother) is laughable nonsense. Yes, protocol buffers have some advantages (and some significant disadvantages), but that is an entirely different discussion, and the attempt to try to pull it in, simplifying it as if it is some sort of solid point (protip: it isn't even close to a trump card. It has advantages, but it certainly doesn't invalidate xml), is transparent nonsense.

Whatever your personal hangups with xml, your scattered and somewhat desperate attempts to try to denigrate anyone who doesn't denounce it is grossly out of place on any place where professionals converse.

Whoa, you have taken my message a lot more personally than I intended my tone to land. I mean, I was being a little bit snippy about technology, but it wasn't meant at all as a personal attack. Sorry if it came off that way.

I wasn't meaning to say that you were unaware of Protocol Buffers, my argument is just Protocol Buffers do achieve most of what XML is trying to achieve, and I think many people don't appreciate that most of the complexity of XML is not inherent to the problem domain, but rather a product of an over-engineered technology stack that is not a good match for the problems to which it is usually applied.

A person who is marking up a text document, like with DocBook, has (in my opinion) the best argument for using XML. For more data structure-oriented programming like SVG or web APIs, I believe Protocol Buffers are better in every way, and I think I can defend that argument in rigorous debate.

If you go to the XML Schema website and print up the two specs there (Part 1 and Part 2), the printed spec is 371 pages. I think it is difficult to make the argument that it is "profoundly simple." The JSON RFC, at 10 pages, would deserve that characterization.

XML Schema describes a language to define a CF-like grammar and a set of extensible types, while JSON is a serialization notation for a data model that has strings, integers, real numbers, booleans, arrays, and dictionaries. No wonder they're different.

Reply on news.ycombinator.com