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

111–120 of 274 posts

Re: When XML Beats JSON: UI Layouts

#111

Post by 52-6F-62 »

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?

Maybe something more like:

    [
        "div",
        [
            "The ",
            [
                "a",
                { "href": "https://www.json.org/" },
                [ "JSON format" ]
            ],
            " was invented by ",
            [
                "em",
                "Douglas Crockford"
            ],
            "."
        ]
    ]
With all children being encapsulated in an array...

edit: though it again gets confusing when the 0 index is sometimes the element type and sometimes the straight text... so never mind I guess the problem persists.

Re: When XML Beats JSON: UI Layouts

#112

Post by LastMuel »

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?

The author makes a case for why it would matter:

> XML, on the other hand, optimizes for document tree structures, by cleanly separating node data (attributes) from child data (elements).

Unfortunately, there appear to be some implementation issues here. You have to create a string version of your data to store them in attributes.

So, you lose a bit of context in the conversion.

Such as:

``

Is the text attribute the word _true_ or a boolean _true_. Without referencing some other piece of code or definition there is no way to know.

Whereas in JSON, this wouldn't be necessary, as you can simply remove the quotes and infer that it is not a string, but a boolean.

Re: When XML Beats JSON: UI Layouts

#115

Post by wtetzner »

jrochkind1 wrote: post #95

I don't disagree that JSON is better than XML for their "list" example,and that XML is better than JSON for their "UI layout" example. BUT: > This means there’s no officially supported way to represent the list of movies in an element attribute. We can hack this by encoding the list into an attribute using a comma delimiter: So, that's because you're doing it wrong. XML has NO PROBLEM with hieararchy, REALLY. Of COUR…

And if you want, you can still keep some of the attributes:

      
        
          
            Diehard
            Threat Level Midnight

Re: When XML Beats JSON: UI Layouts

#116

Post by disease »

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…

After using Flex for a couple of years I have to agree. There always seemed to be two ways to do things: 1) Through the XML 2) Through the code. That may seem appealing initially but gets really ugly when certain developers do certain things with XML and others code. It basically doubles the API space and syntax.

Re: When XML Beats JSON: UI Layouts

#117

Post by marcosscriven »

moron4hire wrote: post #109
marcosscriven wrote: post #68

One thing I really miss when working on JSON vs XML data are comments. A workaround is to make the comment a valid string in the data, but still not as good as having the ability to comment an arbitrary line.

XML has comments. They are the same as HTML comments.

That was indeed my point - whereas one can't in JSON.

Re: When XML Beats JSON: UI Layouts

#118

Post by sacado2 »

adamlett wrote: post #77
sacado2 wrote: post #50

Earlier quoted context omitted.

Well, for instance, let's take the HTML code of your comment (which happens to be a valid XML document): I have yet to read anything that convinces me that XML is good for anything . Just because XML in certain cases is less bad than some other cherry-picked technology, doesn't mean that there aren't other better options. See also Erik Naggum's legendary rant: https://www.schnada.de/grap…

In order for me to answer that, you must be more specific about the purpose of the representation. For the purpose of authoring comments on Hacker News (HN), I for one am grateful= that HN doesn't make us type out HTML. I also doubt very much that HN stores our comments in a different representation (e.g. HTML) than the one they were authored in.

That's a very good point. Thing is, markdown (or a subset of it, as on HN) is very limited. Great for short comments, bad when you want to do something a little more complex, like a blog post (I always end up addding some HTML here and there in my markdown blog posts, when I want to include a video for instance).

The other problem is that HN comments and all those markdown-like formats are very ad hoc. If I copy/paste my reddit comments on HN, or the other way around, it won't always work as expected. In both cases, it has to be translated to HTML to be displayed by the browser, too.

So, the context would be: an export format for complex, multi-paragraphs textual documents with meta-information.

Re: When XML Beats JSON: UI Layouts

#119

Post by [deleted] »

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…

[deleted]

Re: When XML Beats JSON: UI Layouts

#120

Post by chooseaname »

gunn wrote: post #97
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…

It also has the advantage over code that it can be modified with a visual interface designer.

I'm pretty sure Delphi and VB were famously successful in spite of the fact that they didn't use XML for UI layout.
Post reply on HN