> I can't think of any other reason for agreeing with you (thought XPath is reason enough).
Streaming JSON API/parsers are not wide-spread (and definitely not as widespread as SAX-style streaming XML parsers), which makes JSON unusable for datasets which don't fit in memory.
And generally spreaking, I think most people would be satisfied with a CSS-type query language, I'm always surprised by the dislike my colleagues have for xpath and their lack of knowledge of it, even though xpath is one of the very few things I like in the XML infosphere (the other one being RelaxNG)
Is the real pro-XML argument, then, that it currently has support? As far as I know, there is nothing inherent to JSON to prevent anyone from writing a streaming parser.
> Is the real pro-XML argument, then, that it currently has support?
That's the only one I can find which would be relevant to milweed's assertion that:
> Large data sets should be published in XML.
Apart from the rarely used ability to mix data formats into a single semi-coherent document and some sort of backwards compatibility, I don't see much in the way of reason.
> As far as I know, there is nothing inherent to JSON to prevent anyone from writing a streaming parser.
Of course there is not, and there are several such parsers, hence my writing that they are not widespread. Were they impossible (or non-existent) or at the very least unknown to me I'd have written that they don't exist instead.
Streaming JSON API/parsers are not wide-spread (and definitely not as widespread as SAX-style streaming XML parsers), which makes JSON unusable for datasets which don't fit in memory.
And generally spreaking, I think most people would be satisfied with a CSS-type query language, I'm always surprised by the dislike my colleagues have for xpath and their lack of knowledge of it, even though xpath is one of the very few things I like in the XML infosphere (the other one being RelaxNG)