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

When XML Beats JSON: UI Layouts

engineering.instawork.com

Post reply on HN
Print view View original

121–130 of 274 posts

Re: When XML Beats JSON: UI Layouts

#121

Post by wil421 »

hagreet wrote: post #76
wil421 wrote: post #46

Having worked with SOAP/XML extensively at my past job I can say for web services I much prefer REST/JSON. JSON is much easier to work with and key value pairs make it much easier to get what you need. Parsing an XML tree can become a nightmare very quickly. > However, we’ve created another problem in the form of inconsistency: some user properties are represented as element attributes, others as child elements. Exac…

1. Why is parsing a tree which is encoded in JSON easier? 2. Why does it matter if an element is in an attribute or in child elements. You need some kind of schema anyway, right?

It depends on the API of the system. I’ve worked on middleware that would not be able to get an attribute, it lacked the capability. Other systems used JavaScript and it was much easier with JSON

See this link on stack exchange[1].

[1] https://stackoverflow.com/questions/17604071/parse-xml-using...

> //Gets Street name xmlDoc.getElementsByTagName("street")[0].childNodes[0].nodeValue;

I’d much prefer something like jsonObj.address[0].street;. Personally I like to work with objects over parsing documents trees.

Re: When XML Beats JSON: UI Layouts

#122

Post by mumblemumble »

nodamage wrote: post #90

At this point I am convinced that the decision to define UI layouts in XML instead of code has been a terrible mistake. - For starters, it's overly verbose. If you've worked with stuff like XAML in WPF or XML layouts on Android, you know how quickly those files tend to get bloated. - It does not lend itself well to reuse compared to, well, actual code. Which means there tends to be a lot of repetition. Which leads to…

My suspicion is that XML and friends get chosen for compelling social reasons.

It's not a language that anyone would want to do the actual software implementation in. That's important because, if you pick an existing language, then everyone who plans to use some other language is going to see that choice and assume it means that their language is either unsupported or will be a second-class citizen on that UI toolkit. They might not be wrong.

Creating a whole new language that's custom-tailored for UI layout avoids that problem, but will also be off-putting, since people will perceive that they have to learn a whole new language just to use your UI toolkit.

And just slapping it into a mess of library calls that people can call from any language is perhaps the worst choice of all. GUI toolkits, for whatever reason, always end up being object-oriented. Meaning that you've got to export an object-oriented API. Meaning you've got to either implement it in an object-oriented language that probably has a deeply incompatible and possibly not even standardized ABI such as C++, or you've got to go to great lengths to Greenspun an object-oriented system into a procedural language that can export a C-style ABI. Neither of those is fun.

In summary. . . yeah, XML is an awful choice. It's easily the worst option, aside from all the other options, which are even worse.

Re: When XML Beats JSON: UI Layouts

#123

Post by kgwxd »

superqd wrote: post #98

I stopped reading at the example describing how to provide an org chart relation as XML. The argument here failed for me, and made the notion of what is "clean" code or "clean" structure even more subjective than ever. The JSON version of the employee org chart is much more semantic and human understandable (to me) as it "cleanly" describes the relationship for reports as a property called "reports" (for those who ma…

They both looked fine to me but human readability shouldn't be the primary goal of a data format. I think the example is bad for both formats because it conflates tree data structures and logical hierarchy. The memory model of the application consuming the data would likely look like that, but that doesn't mean that's how it should be stored/transmitted, that should be probably be flattened, with each employee having a "manager" property.

Re: When XML Beats JSON: UI Layouts

#124

Post by magicalhippo »

taeric wrote: post #87
vbezhenar wrote: post #74

Earlier quoted context omitted.

> Numbers can be expressed, they just have to be parsed on the client. But client has to know that they're numbers. So you can't just parse XML into JavaScript object without any knowledge about its structure. > For array, child elements are ordered and form an array naturally. But you can't express array of 0-length this way without explicit knowledge about structure. And you can't distinguish array of 1-length from…

Odd that you would pick numbers. Those are not exactly but free in json. And dates are as likely to actually be a problem.

> And dates are as likely to actually be a problem.

I'm currently working against a REST API which JSON format has three different date formats as sub-elements of the same root object...

Re: When XML Beats JSON: UI Layouts

#125

Post by dnautics »

Kuinox wrote: post #64
sacado2 wrote: post #41

What XML is also very good at is: representing tagged text, what is called "mixed content" in XML terminology. Just try to write the JSON equivalent of: The JSON format was invented by Douglas Crockford . If your document consists mainly in losely structured text with some annotation, you better use XML.

So Jupyter Notebooks should be XML instead of JSON. Right ?

Honestly, they should be markdown. This would also solve the versioning problem.

Re: When XML Beats JSON: UI Layouts

#126

Post by keymone »

arethuza wrote: post #61
sacado2 wrote: post #41

What XML is also very good at is: representing tagged text, what is called "mixed content" in XML terminology. Just try to write the JSON equivalent of: The JSON format was invented by Douglas Crockford . If your document consists mainly in losely structured text with some annotation, you better use XML.

{ "type": "div", "children": [ "The ", { "type": "a", "attributes": { "href": " https://www.json.org/" }, "children": [ "JSON format" ] }, " was invented by ", { "type": "a", "children": [ "Douglas Crockford" ] } ] } I think I prefer the XML :-) Edit: I agree that tagged text is a clear win for XML - for pretty much everything else I'd go for JSON. Edit2: HN ate my formatting, but probably not a bad thing ;-)

Check out hiccup

Re: When XML Beats JSON: UI Layouts

#127

Post by mdtusz »

m1el wrote: post #78

> JSON for lists, XML for trees No. JSON is a recursive data structure that can represent trees as well. It's easy to make a concise representation of DOM trees as JSON: http://m1el.github.io/jsonht.htm I find it really sad that people don't know or consider s-expressions to represent trees. (Department {:name "Scranton Branch"} (Employee {:name "Michael Scott" :title "Regional Manager"} (Department {:name "Sales"} (…

There's a beautiful symmetry between s-expressions and XML which is why it's not really all that annoying to work with once you approach it as an s-expression.

Re: When XML Beats JSON: UI Layouts

#128

Post by kgwxd »

wil421 wrote: post #46

Having worked with SOAP/XML extensively at my past job I can say for web services I much prefer REST/JSON. JSON is much easier to work with and key value pairs make it much easier to get what you need. Parsing an XML tree can become a nightmare very quickly. > However, we’ve created another problem in the form of inconsistency: some user properties are represented as element attributes, others as child elements. Exac…

I still work with SOAP occasionally. I'd never recommend anyone start a new project with it, but I've never had to manually parse anything. Did the framework you had to work with not provide decent XSD/Class code generation and serialization/deserialization tools?

Re: When XML Beats JSON: UI Layouts

#130

Post by m1el »

sacado2 wrote: post #103
m1el wrote: post #84

Earlier quoted context omitted.

["div", "The ", ["a", {"href": " https://www.json.org/" }, "JSON format"], " was invented by ", ["em", "Douglas Crockford"], "."]

Quite readable but it's a hell to parse. The first argument is the name of the element, but what is the second one? If it is a string or an array, it's the first child, but if it's an object, it's the attribute set?

> The first argument is the name of the element, but what is the second one?

If the second argument is an object/dictionary, it's attributes. Otherwise, it's the first child. Alternatively, the ambiguity can be resolved by using null/0 instead of empty attributes.

Post reply on HN