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

251–260 of 274 posts

Re: When XML Beats JSON: UI Layouts

#251

Post by Mikhail_Edoshin »

nodamage wrote: post #235
gjulianm wrote: post #131

Earlier quoted context omitted.

I don't agree very much with your take. - User interfaces are very prone to have big files, because there tend to be a lot of different components. I don't get how XML will add more bloat, other than having the tags for defining elements. - XAML lets you define custom controls. I'm not familiar with Android XML, but in any case it's not an issue of the language but of the framework. - Again, a fault of the framework.…

> - User interfaces are very prone to have big files, because there tend to be a lot of different components. I don't get how XML will add more bloat, other than having the tags for defining elements. I disagree that this is an inherent property of user interfaces. In fact I think it's a bit weird that we focus so much on abstractions and when it comes to the code we write (DRY principle, etc), but then when it comes…

Namespace prefixes in XML can be a) shortened and b) removed by setting the default namespace. I.e. the following are equivalent:
These forms can happily co-exist in the same document, e.g. you can start at the top with one default namespace and then switch it in some branch into another.

Re: When XML Beats JSON: UI Layouts

#252

Post by Mikhail_Edoshin »

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…

I want to address that reuse/repetition thing. It's totally possible to do this in XML+XSLT. E.g. you have some repeating structure that totally calls for what would be a helper function in a conventional language, say, "createMyButton(this, that)". In XML that could be done like this:
This gets fed into an XSLT file that copies everything intact and expands your custom elements:

Re: When XML Beats JSON: UI Layouts

#253

Post by Mikhail_Edoshin »

mrlala wrote: post #156
OskarS wrote: post #79

You know, when XML looks like this, I don't mind it so much: The thing is, XML in the real world never looks like this . In the real world, XML has an avalanche of obscure namespaces, weird " The simplicity of JSON is an advantage: it prevents people from mucking it up with too much nonsense like this. Of course, you CAN make unreadble JSON as well, XML just makes it so much easier.

That still looks extremely confusing.. if I didn't know who those people were, I would have a really hard time even noticing that there is a hierarchy in what you presented. And even still, that just doesn't look intuitive to me. Probably because there is no distinction between an employee and a list of employees linked to a parent employee?

The structure of XML (which element contains which) was meant to be used to link these elements to the underlying text they're marking up. When there's no text and just metadata (elements), there's no natural structure for them. It can still exist, of course, but what it means is totally up to the designer of this XML format. It's piggybacking the structural relation for something else. In this example it's piggybacked for "boss-employee" relation, but it could totally be flat like that:

Re: When XML Beats JSON: UI Layouts

#254

Post by Mikhail_Edoshin »

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.

The information stored in this XML is essentially that:

    { "string": "The JSON format was invented by Douglas Crockford",
      "structure" [
        [ 0, 48, "div", {} ],
        [ 4, 13, "a", { "href": "https://www.json.org" } ],
        [ 32, 48, "em", {} ]
      ]
    }
(If we allow empty elements, we'd need another field in the structural entries to be able to reconstruct the hierarchy.) Now I'd say that XML way to combine these three kinds of data is pretty elegant and natural. The JSON would be impossible to write by hand, although it's good for machine processing.

Upd: The three kinds of data: the string, the structures (div, a, em), and their position in the string.

Re: When XML Beats JSON: UI Layouts

#255

Post by Mikhail_Edoshin »

jancsika wrote: post #151
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.

It's funny to me that even in an XML shining example of purpose you've got non-semantic " " there likely because, "just float where I want, dammit!" Just imagining a JSON that starts with "dummy": "don't remove this or the API will mis-align this across two structs!!!"

The semantic of these things is what the code does with them. It's the only semantic there is. E.g. the tag has perfect semantic, while not that much.

Re: When XML Beats JSON: UI Layouts

#256

Post by Mikhail_Edoshin »

falcolas wrote: post #85
hyperman1 wrote: post #32

Interesting to see the history here: XML was created and solved a lot of problems. So on the bandwagon everybody jumps. Then it became bloated and fragmented, so the world switches mostly to JSON. But on the XML side, the baby was thrown out with the bath water, while JSON started developing its own abuses. TOML and YAML come in and muddy the waters a bit more. This is only 1 article, but maybe the world is ready to…

The moment we added JSON schema (not to mention JSON transforms) and started to create a JSON version of XPath, we started down the same path that hurt XML. Throw in parsers that all act differently (some parse comments, some don’t), and processing directives, and it becomes clear that yes, the pendulum has swung too far.

Imagine you're Amazon and you receive data from vendors. It's not enough to authenticate the sender, you still need to check that the payload is at least syntactically valid before starting to process it. You can write custom code, of course, but after writing lots of it you're likely to start naturally splitting it into a declarative part and a universal processor that checks incoming data against the declaration. It's harder to come up with a declarative way from the start, but it's a natural tendency, because declarative form is much simpler than procedural: declarations are data, and data are easier to understand than a process.

This is what schema, transforms, and paths are: they're a declarative way to address these tasks in XML. It's natural there will be attempts to reinvent them for JSON.

Re: When XML Beats JSON: UI Layouts

#257

Post by Mikhail_Edoshin »

patsplat wrote: post #209
hyperman1 wrote: post #32

Interesting to see the history here: XML was created and solved a lot of problems. So on the bandwagon everybody jumps. Then it became bloated and fragmented, so the world switches mostly to JSON. But on the XML side, the baby was thrown out with the bath water, while JSON started developing its own abuses. TOML and YAML come in and muddy the waters a bit more. This is only 1 article, but maybe the world is ready to…

YAML predated / was concurrent with JSON. Both were in reaction to the bloat of XML.

It's funny that YAML spec is three times as long as XML 1.0.

Re: When XML Beats JSON: UI Layouts

#258

Post by Mikhail_Edoshin »

lucideer wrote: post #188
pytester wrote: post #34

Earlier quoted context omitted.

>$schema and $ref are differentiated by convention in JSON, and require repeated consideration in every parsing scenario to treat them as exceptions relative to actual values within the JSON document. This is a good thing. The main issue with XML is how ridiculously overcomplicated and overengineered its design was. This isn't just a matter of usability, it has security implications because it increases the attack su…

> This is a good thing. The main issue with XML is how ridiculously overcomplicated and overengineered its design was. Citing element attributes as an example of such complexity is hardly reasonable. The JSON example above contains the same complexity, just moved to the application/implementation space, instead of the parser (so your app is more complex to handle it). > e.g. the XML billion laughs attack Also not a g…

I would disagree about having more value types. JSON has more syntax for value types, but it only has four: string, integer, float, and boolean. XML has less syntax for value types (everything is serialized as a string), but it has a way to define types of attributes with XML Schema and there you get much more primitive types already (decimal, date & time, binary). XML approach is more uniform: it uses schema to look up all the parsing rules. JSON uses syntax for some types and (ad-hoc) schema-like logic for others.

Re: When XML Beats JSON: UI Layouts

#259

Post by paulio »

WiseWeasel wrote: post #238
paulio wrote: post #161

Earlier quoted context omitted.

I agree. I think the argument isn't json/xml/yaml/crazy it's why isn't this just code.

Because sometimes you want to pass data between blobs of code, (possibly separated by time, environment or language), or even to and from humans who may not understand code.

of course, but for a ui?

Re: When XML Beats JSON: UI Layouts

#260

Post by itafroma »

sacado2 wrote: post #53
halfdan wrote: post #36

Earlier quoted context omitted.

Does https://json-schema.org/ not work for you?

I don't know JSON schema really well; Can you say you want a `price` value to be a non-negative decimal value with at most two digits after the comma, and you want the `currency` value be exactly one of the following : "EUR", "USD", "GBP", the default if not specified being "EUR"?

Yes:

    {
        "$schema": "http://json-schema.org/draft-07/schema#",
        "type": "object",
        "properties": {
            "price": {
                "type": "number",
                "multipleOf": 0.01,
                "minimum": 0
            },
            "currency": {
                "type": "string",
                "enum": ["EUR", "USD", "GBP"],
                "default": "EUR"
            }
        }
    }
Post reply on HN