On 09/30/2014 03:34 PM, Michael Kay wrote:
> I think the "fat" referred to by the phrase "fat-free alternative to
> XML" has very little to do with data size, it has much more to do with
> complexity: the fact that the JSON specification fits on one sheet of
> paper, whereas XML extends to thousands of pages if you include the
> whole stack.
I had a few too many conversations with programmers which ran like:
ME: What's so hard about parsing a tree?
PROG: The tree part is easy. The hard part is knowing what it all means.
ME: Sure - but doesn't that get simpler when you get familiar with the
markup languages you use?
PROG: Familiar? What do you mean? I feed the schema to the program,
and then I spend forever trying to figure out why things won't validate.
ME: Do you ask the person who sent you the document?
PROG: Sure, but sometimes it's my own code that won't create content
that matches the schema, and then I have to know all the details.
ME: Have you tried looking through sample documents?
PROG: Sure, and they validate. Then I try to do something sliobscure
type and sequence issuesghtly different and I can't figure out why
slightly different doesn't validate. [Lists corner cases, cites
half-remembered specifications, sputters.]
ME: Sounds painful.
That's one relatively small component of a much larger repeated
conversation, but it was probably the most frequent part of it from
about 2001-2006. Yes, I've heard echoes of the same conversation around
JSON schemas as well. No, of course I don't think they're approaching
the challenge or the standards the right way, but it keeps happening.
(I had plenty of difficult conversations before XML Schema dominated,
but with a different cast of mostly tool-related challenges.)
Thanks,
Simon