Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

JSON Feed

jsonfeed.org

Post reply on HN
Print view View original

211–220 of 225 posts

Re: JSON Feed

#211

Post by rspeer »

jancsika wrote: post #203
josteink wrote: post #198

Earlier quoted context omitted.

You never know. This is what they said about schemas too not many years back.

Have there been any discussions whatsoever about adding some sort of namespacing mechanism to JSON?

Well, there's JSON-LD (JSON Linked Data) already.

It's for making interoperable APIs, so there is a good motivation for namespaces. But the namespaces are much less intrusive than XML namespaces. Ordinary API consumers don't even have to see them.

One of the key design goals of JSON-LD was that -- unlike its dismal ancestor, RDF/XML -- it should produce APIs that people actually want to use.

Re: JSON Feed

#212

Post by abritinthebay »

mindcrime wrote: post #78
pfranz wrote: post #47

Earlier quoted context omitted.

Part of me is with you. But even in established languages I've had trouble finding an appropriate xml parser and had to tweak them way more than I thought necessary. I haven't (yet) had that problem with JSON. I think with something like feeds there's the possible benefit of becoming a 'hello world' for frameworks. Many frameworks have you write a simple blogging engine or twitter copycat. I don't think I've ever see…

But even in established languages I've had trouble finding an appropriate xml parser and had to tweak them way more than I thought necessary. I haven't (yet) had that problem with JSON. Maybe it's just that I work mostly with JVM languages (Java, Groovy, etc.) but I haven't had any problems with handling XML - including Atom - in years. But I admit that other platforms might not have the same degree of support.

> Maybe it's just that I work mostly with JVM languages (Java, Groovy, etc.) but I haven't had any problems with handling XML

Yeah, no surprise. XML may as well be a native data-type in most core JVM languages.

It's not the case everywhere else however.

Re: JSON Feed

#213

Post by abritinthebay »

mindcrime wrote: post #139
sacheendra wrote: post #126

Earlier quoted context omitted.

IMHO the boilerplate code is much easier to read than understanding the nuances of XML if I have to read a document. {"type":"currency", "unit":"euro", "amount": 10} feels easier to understand than 10

Maybe it's just conditioning, but I find the latter example easier to read and understand. In fact, I'd say that - in general - I find XML better in terms of human readability than JSON. I guess it just goes to show that we all see certain things differently. shrug

I think that's totally reasonable - because it was after all one of the goals of XML. That is, to be human readable.

There is a difference however between readable + parsable vs parsable + easily dealt with.

XML was not the latter. You have to do more work to traverse and handle XML inside your application than you do JSON, and most of the (reasonable) reasons for this are due to features that most cases don't need.

JSON makes the common case easy, XML doesn't.

Re: JSON Feed

#216

Post by nonodename »

zokier wrote: post #118
mstade wrote: post #28

Earlier quoted context omitted.

If there was an `XML.parse` just like there's `JSON.parse`, I doubt you'd say the same. As it stands, the added complexity in JS-land is to import a library that provides this functionality for you. Fortunately there are many, but I agree a built-in would be nice. It's a bit of a shame that E4X never landed in JS.

XML is fundamentally much more complex than JSON so any XML parsing library will inevitably present more complicated API. I kinda like XML (!), but there is no point pretending that using it is as simple as JSON.

Absolutely. Right tool for the right job. Mixed content (perhaps a paragraph with bold and italics) is absolutely horrible in JSON because it lacks the complexity that XML has to cope with this.

Re: JSON Feed

#217

Post by vsl »

philsnow wrote: post #89
tetrep wrote: post #52

Earlier quoted context omitted.

As terrible as XML parsers can be, they've never been as bad as "XMLdoc = eval(XMLString)". I'd be more likely to trust a JSON parser not written in JavaScript than an arbitrary XML parser, but that's only because of the XML specification itself, which includes such features as including arbitrary content as specified by URLs (including local (to the parser) files!). Great ideas when you can trust your XML document,…

modern browsers don't internally call eval(). See e.g. the definition of JSON.parse in v8: https://chromium.googlesource.com/v8/v8/+/4.3.65/src/json.js...

And modern XML parsers aren't full of vulnerabilities anymore. You're missing the point.

Re: JSON Feed

#218

Post by ajanuary »

eponeponepon wrote: post #210
duskwuff wrote: post #111

Earlier quoted context omitted.

It's kind of tough to convert XML directly to other formats (including, but not limited to, JSON), because there are a lot of XML features that don't map cleanly onto JSON, such as: • Text nodes (especially whitespace text nodes) • Comments • Attributes vs. child nodes • Ordering of child nodes

As it happens, XSLT 3.0 and XPath 3.0 both have well documented and stable features for doing exactly this. Roundtripping XML to JSON and back is a solved problem - check it out some time; it may surprise you.

Are you talking about json-to-xml and xml-to-json?

From the XSLT spec [0]:

"Converts an XML tree, whose format corresponds to the XML representation of JSON defined in this specification, into a string conforming to the JSON grammar"

It can't take an arbitrary XML document and turn it into JSON, it can only take XML documents that conform to a specific format.

You can safely round-trip from JSON to XML and back to JSON. That's trivial because JSONs feature set is a subset of XMLs.

What you can't safely do is round-trip from arbitrary XML to JSON and back to XML. That's because, as the parent said, there are features in XML that don't exist in JSON. That means you are forced to find a way to encode it using the features you do have, but then you can't tell your encoding apart from valid values.

[0] https://www.w3.org/TR/xslt-30/#func-xml-to-json

Re: JSON Feed

#219

Post by jancsika »

rspeer wrote: post #211
jancsika wrote: post #203

Earlier quoted context omitted.

Have there been any discussions whatsoever about adding some sort of namespacing mechanism to JSON?

Well, there's JSON-LD (JSON Linked Data) already. It's for making interoperable APIs, so there is a good motivation for namespaces. But the namespaces are much less intrusive than XML namespaces. Ordinary API consumers don't even have to see them. One of the key design goals of JSON-LD was that -- unlike its dismal ancestor, RDF/XML -- it should produce APIs that people actually want to use.

Thanks, I haven't explored JSON-LD before.

But that's not a case of adding namespaces to JSON, is it?

What I mean is if one were to take the skeptical position that JSON is going to end up "re-inventing the XML wheel", that would mean JSON advocates would need to push namespaces into the JSON spec as a core feature of the format. I've never read a discussion of such an idea, but I'd like to if they exist.

edit: clarification

Re: JSON Feed

#220

Post by duskwuff »

ajanuary wrote: post #218
eponeponepon wrote: post #210

Earlier quoted context omitted.

As it happens, XSLT 3.0 and XPath 3.0 both have well documented and stable features for doing exactly this. Roundtripping XML to JSON and back is a solved problem - check it out some time; it may surprise you.

Are you talking about json-to-xml and xml-to-json? From the XSLT spec [0]: "Converts an XML tree, whose format corresponds to the XML representation of JSON defined in this specification, into a string conforming to the JSON grammar" It can't take an arbitrary XML document and turn it into JSON, it can only take XML documents that conform to a specific format. You can safely round-trip from JSON to XML and back to JS…

You could conceivably serialize the DOM as a JSON object, but the representation would be very difficult to work with:

    {
      "type": "element",
      "name": "blink",
      "attributes": {
        "foo": "bar"
      },
      "children": [
        {
          "type": "text",
          "content": "example text"
        }
      ]
    }
Post reply on HN