How to Avoid Being Called a Bozo When Producing XML (2005) • Hacker News Board

Re: How to Avoid Being Called a Bozo When Producing XML (2005)

#181

Post by brightball » Mon, Aug 01, 2016, 3:16 AM UTC

cptskippy wrote: post #18

XML is well regarded in the enterprise and languages like JAVA, C#, and VB.NET handle is spectacularly as an exchange format. I think it's bad reputation comes from anyone not using an enterprise language because the support just isn't there. I recall working with a partner who we were doing an identity federation with. Our system was using WS-Trust which is a SOAP/XML protocol. It wasn't ideal but everyone seemed to…

Another part of it is that statically typed languages benefit much more from XML with a strictly defined schema like DTD or XSD because it makes it easier to generate the objects that you're going to have to map it into.

With a language like Ruby, PHP, etc that isn't strongly typed it's not nearly as big of a deal. Developers in those languages are used to assuming everything is a string and converting it to something useful without the need to premap every datatype.

That's probably the main reason that XML was so much more popular with the languages you mention compared to the parts of the ecosystem that didn't benefit from it's constructs much (if at all).

Re: How to Avoid Being Called a Bozo When Producing XML (2005)

#182

Post by mikeash » Mon, Aug 01, 2016, 3:51 AM UTC

erlehmann_ wrote: post #151

MichaelGG wrote: post #105

Earlier quoted context omitted.

XML's bad rep for verbosity is almost entirely due to the nonsensical, terrible idea of requiring names in the end tag. Without that, it's about the same level of verbosity as JSON. And personally, after writing plenty of both by hand, XML is easier to get right. JSON, with it's poor quoting rules (mandatory quotes on names??) and lack of comments is very annoying to do by hand and seems visually more noisy.

An advantage of names in end tags is human readability. Consider this XML fragment: 12 34 56 78 90 Appending something to the end of the d element is easy, since one can just search for its end tag. In JSON and other formats that only have one single character at the end, one has to count brackets or parentheses for this purpose: (12(34(56(78(90)))))

If they're all then you're back to square one.

JSON solves this with indentation, pretty printing, and using paired symbols that most conpetent editors can automatically balance. This solves the homogeneous case too.

Incidentally, XML can benefit from the first two, and many editors balance tags, so you can get the same thing there.

Re: How to Avoid Being Called a Bozo When Producing XML (2005)

#183

Post by piaste » Mon, Aug 01, 2016, 5:43 AM UTC

flukus wrote: post #148

SomeCallMeTim wrote: post #125

Earlier quoted context omitted.

>In those cases, I would rather have XML config files than undocumented binary blobs as config files. False dichotomy. Better than XML and binary blobs: * JSON (assuming everyone knows what this is) * YAML [0] * Lua tables (if you're already using Lua as a scripting language; Lua started out as a configuration language after all) * INF format [1] (not my favorite, but pretty easy to parse and much better for humans t…

> JSON (assuming everyone knows what this is) The new .net uses json, it's awful. No comments allowed and it get's pretty unreadable when you have nested configuration elements.

VSCode uses comments for every line in its settings.json file.

I guess they figured it may not be correct JSON, but since they aren't sending those particular JSON files anywhere it doesn't matter?

Re: How to Avoid Being Called a Bozo When Producing XML (2005)

#184

Post by MichaelMoser123 » Mon, Aug 01, 2016, 6:27 AM UTC

zachrose wrote: post #140

nialo wrote: post #127

Earlier quoted context omitted.

Can you explain what you mean by JSON being an edge labeled tree in more detail? I don't understand and would really like to.

Taking a stab at this... Let's say we have a dog who has four paws. In XML: In JSON: { "paws": [ { "health": "ok" }, { "health": "ok" }, { "health": "ok" }, { "health": "ok" }, ] } I think what the GP is getting at is that JSON is always describing the relationships between a thing and another thing, rarely the things themselves. In the JSON version, for example, it can be assumed that an object in the "paws" array i…

I don't quite see why you can't do the same with xml; maybe it needs some more typing, but it is expressing the same thing.

i thought that the main advantage of json was that it can be used as is (code as data) in javascript, but the problem here of course is that without a parser/validator one can inject tons of malicious code. If you are not on javascript then you can't do without a parser / in memory tree structure - and that's the same DOM model once again.

Json needs a bit less typing, now is that really such a significant difference? i think that adoption in matters of markup is more like a fashion - once people got the hang of it then it seems natural and goes without explanation.

i would say that there is one major difference - binary or text; as long as its text then it doesn't quite matter how you structure your markup; if you need your data to be of small size then you will have to compress it; however the parsing of a text tree will usually take more time than the serialization of a binary structure (by several factors);

Therefore you will use text markup where application speed is not very important, or where speed of development is more important than application performance, or you will use it for complicated configuration data (and your users will hate you because a name value format like ini files is easier to handle - well, mostly)

Re: How to Avoid Being Called a Bozo When Producing XML (2005)

#185

Post by ZenoArrow » Mon, Aug 01, 2016, 6:52 AM UTC

legulere wrote: post #99

ZenoArrow wrote: post #50

Earlier quoted context omitted.

> "The best human-readable data transfer format is probably canonical S-expressions" I personally think TOML is a bit more readable... https://github.com/toml-lang/toml

For configuration files, not for data serialisation.

Let's put it like this... what can you express in JSON that you couldn't express in TOML?

Re: How to Avoid Being Called a Bozo When Producing XML (2005)

#186

Post by groovy2shoes » Mon, Aug 01, 2016, 7:07 AM UTC

bane wrote: post #110

My "favorite" XML formats are the one that are just some kind of weird meta-format and don't really use any of the XML features: blah blah this is the attribute value ... And yes, these types of abominations are everywhere. The only way to avoid being called a Bozo when producing XML is to either a) ensure that humans never had to see this craziness b) don't use XML XML as a config file format, in particular, is prob…

You're going to "love" this little guy: http://txti.es/barry/xml

Only slightly better is the JSON counterpart: http://txti.es/barry/json

Re: How to Avoid Being Called a Bozo When Producing XML (2005)

#187

Post by cytzol » Mon, Aug 01, 2016, 7:13 AM UTC

spdionis wrote: post #134

geerlingguy wrote: post #132

Earlier quoted context omitted.

Ansible uses Jinja2 to output templates in whatever format is preferred by the thing being configured. I haven't personally seen Ansible used to output YAML... But people will do anything :-P Ansible does use YAML as a configuration language though—something for which it's perfectly suited.

Well, some frameworks use yaml for config files and you might use ansible to write those. That said the templating is usually trivial, just maybe write some string values.

I’ve done it. It’s painful enough that it teaches you “don’t do this!”. For example, you need to escape `{{ item }}` as `{{ "{{" }} item {{ "}}" }}`!

Re: How to Avoid Being Called a Bozo When Producing XML (2005)

#188

Post by erlehmann_ » Mon, Aug 01, 2016, 7:19 AM UTC

mikeash wrote: post #182

erlehmann_ wrote: post #151

Earlier quoted context omitted.

An advantage of names in end tags is human readability. Consider this XML fragment: 12 34 56 78 90 Appending something to the end of the d element is easy, since one can just search for its end tag. In JSON and other formats that only have one single character at the end, one has to count brackets or parentheses for this purpose: (12(34(56(78(90)))))

If they're all then you're back to square one. JSON solves this with indentation, pretty printing, and using paired symbols that most conpetent editors can automatically balance. This solves the homogeneous case too. Incidentally, XML can benefit from the first two, and many editors balance tags, so you can get the same thing there.

It is rare in real-world XML that elements have children with the same type. Do you have a (non-divitis) example where the tags are all the same?

Re: How to Avoid Being Called a Bozo When Producing XML (2005)

#189

Post by erlehmann_ » Mon, Aug 01, 2016, 7:27 AM UTC

wtbob wrote: post #162

erlehmann_ wrote: post #149

Earlier quoted context omitted.

The second and third examples do not have namespaces. How would you include an HTML summary, for example?

> The second and third examples do not have namespaces. > How would you include an HTML summary, for example? As a text attribute, honestly — which would be necessary in XML as well (you could embed XHTML in XML, but not HTML). And in the general case, embedding one variant of XML inside another, rather than embedding a character-encoded variant of XML inside another, doesn't seem all that useful. How often do transf…

> How often do transforms need to reach all the way in like that?

In my experience, almost every time XSLT is used on real-world documents, those are documents with multiple namespaces. XSLT stylesheets themselves are also documents that have multiple namespaces. Example: Atom feeds often contain XHTML content. It is a common problem with RSS that it does not specify if the content of an element is HTML or plain text.

I have found that arguments that doubt a feature is necassary from people who can not imagine use cases are almost invariably wrong, while arguments that doubt a feature is necessary from people who list use cases and why they think those are better solved otherwise or even left unsolved are often right. Your post seems like an example of the former; would you say that complex real-world content with namespaces could sway you in favor of them?

Re: How to Avoid Being Called a Bozo When Producing XML (2005)

#190

Post by Mikhail_Edoshin » Mon, Aug 01, 2016, 7:29 AM UTC

bane wrote: post #158

brightball wrote: post #141

Earlier quoted context omitted.

The biggest advantage of XML was the detailed schema validation. Having a uniform and flexible way to both generate data structures and ensure that their contents was valid before ever attempting to process them was handy. XML had a lot of warts but most of its strengths are still seeking passable implementations in JSON. Protocol Buffers is probably the closest thing to being standard in that area for schemas and ge…

Yeah, I acknowledge that bit. But I also think the various schema definition languages (DFDs, XSD, whatever) turned out to be either not expressive enough (DFDs), or a complete PIA (XSD) and in the end, they weren't used very often. Still, it's nice to have them when you need them and when they aren't there it hurts.

Relax NG validation is very good; it's more expressive than XSD and it has both XML and non-XML forms and looks very nice.