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)

#131

Post by bane » Sun, Jul 31, 2016, 9:26 PM UTC

mwfunk wrote: post #121

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…

I don't necessarily disagree, except for the last point. I've rarely (never?) encountered XML used as a config file format where users were expected or encouraged to edit that config file directly vs. using other tools or APIs to touch the file. In those cases, I would rather have XML config files than undocumented binary blobs as config files. When I see an XML config file, I feel a little relief that it's not a bin…

I've mostly come across XML config files that are meant to be edited by humans in various programs that use some kind of Java framework as the back-end.

I don't Java much, so I'd be hard pressed to remember the various framework names (Spring maybe?) but I remember at one point writing a Python script to de-XML the config files into something that was just a bunch of key=values, then another Python script to convert it back to the required XML. IIR on that project, the handful of config options that needed to be tweaked were spread across a dozen or so different XML files.

If the framework could have just read a .txt file with key=values in it, config changes would have gone from 10 minutes to 30 seconds. I eventually just wrote a python thing that auto-deployed and configured the entire stack after asking you a couple questions.

It was absurd.

I believe Android development does (used to?) require lots of hand XML editing. Most of which just drives a Java code generator. I guess the tooling is better these days, but it was enough to drive me away.

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

#132

Post by geerlingguy » Sun, Jul 31, 2016, 9:26 PM UTC

ams6110 wrote: post #87

nrser wrote: post #77

Earlier quoted context omitted.

i think a major problem is that XML kinda looks and feels like HTML (and there was the whole XHTML thing to further confuse), and outputting HTML programmatically (vs string / print / template based) has most been frowned on as overweight and cumbersome. you come from web dev doing HTML like that and you see XML and think "hey, that looks the same, i'll do it in the same way". XML is a programmatic data exchange form…

>YAML, which most people would never think of outputting as templates Don't tell the Ansible folks!

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.

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

#133

Post by andrewflnr » Sun, Jul 31, 2016, 9:38 PM UTC

SomeCallMeTim wrote: post #125

mwfunk wrote: post #121

Earlier quoted context omitted.

I don't necessarily disagree, except for the last point. I've rarely (never?) encountered XML used as a config file format where users were expected or encouraged to edit that config file directly vs. using other tools or APIs to touch the file. In those cases, I would rather have XML config files than undocumented binary blobs as config files. When I see an XML config file, I feel a little relief that it's not a bin…

>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…

GP is obviously not stupid enough to think that XML and binary are the only options. Their whole point seemed to be that they've seen enough binary blobs in practice that even XML was a welcome step up.

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

#134

Post by spdionis » Sun, Jul 31, 2016, 9:55 PM UTC

geerlingguy wrote: post #132

ams6110 wrote: post #87

Earlier quoted context omitted.

>YAML, which most people would never think of outputting as templates Don't tell the Ansible folks!

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.

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

#135

Post by spdionis » Sun, Jul 31, 2016, 10:06 PM UTC

0xcde4c3db wrote: post #100

cillian64 wrote: post #61

Earlier quoted context omitted.

Surely it depends where your output is going? Print and friends are ideal for producing human-readable output, especially when it is temporary, for monitoring or debugging. And they are awful for producing stable machine-readable output which you might want to store. If I'm trying to output straight to a user sitting in front of a terminal, they are going to be very unhappy if I output XML at them. And if my program…

I think the benefit of a serialization library is going to depend on how complex and dynamic your actual output is. I've done XML-by-printing, but in that case the XML elements were fixed scaffolding with no relation to our internal object hierarchy (A containing array of B containing array of C containing array of D, always, regardless of how our application changed). It was also on an embedded system for which addi…

If I need to communicate with a couple of external endpoints that need 5-10 lines of mostly static xml amd the templating is simple i often might prefer using a static templated xml file.

It's much easier to understand what's happening later.

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

#136

Post by oceanswave » Sun, Jul 31, 2016, 10:15 PM UTC

MichaelGG wrote: post #111

oceanswave wrote: post #96

Earlier quoted context omitted.

I also mentioned projects written in Ruby and Java, but that's ok. VB.Net also has XML Literals. Ha ha.

VB's XML literals are just shortcuts for creating the corresponding classes though, right? That's quite a bit different.

Was being a bit sardonic in my comment due to where the discussion went, but yeah, XML Literals in VB.Net create XDocument instances and are just like string literals except:

* Enclosing quotes aren't required * Assumed to be multi-line so line continuation characters aren't required * Are validated for being well-formed XML by the compiler (and at design-time, if VS) * Can have embedded expressions

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

#137

Post by wtbob » Sun, Jul 31, 2016, 10:18 PM UTC

JoshTriplett wrote: post #124

wtbob wrote: post #115

Earlier quoted context omitted.

> A few changes would make XML closer to ideal: eliminate attributes and eliminate the name in closing tags ( value ), which makes child elements much less verbose, and reduces the need for attributes. Then just change ' ' to '(tagname,' and ' ' to ')' and you'll have S-expressions. Consider this: (feed (version 1) (title "Example Feed") (link http://example.org/) (updated "2003-12-13T18:30:02Z") (author (name "John…

If you're going to compare the two fairly, include appropriate indentation for both, not just the S-expression version. Also put the author and name tags on the same line, as you did with the S-expressions: Example Feed http://example.org/ 2003-12-13T18:30:02Z John Doe urn:uuid:60a76c80-d399-11d9-b93C-0003939e0af6 Atom-Powered Robots Run Amok http://example.org/2003/12/13/atom03 urn:uuid:1225c695-cfb8-4ebb-aaaa-80da3…

> If you're going to compare the two fairly, include appropriate indentation for both, not just the S-expression version.

When I pasted it in from https://validator.w3.org/feed/docs/atom.html#sampleFeed I guess I lost the indents. No idea why: they are clearly there in the original.

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

#138

Post by zo1 » Sun, Jul 31, 2016, 10:18 PM UTC

beagle3 wrote: post #49

I used to hate doing XML in Python - ElementTree was the nicest of them 10 years ago, but it still hurt. But last year, I discovered xmltodict[0] and since then, I don't really care - it makes doing xml (both reading and writing) no more cumbersone than using dicts, while still supporting stuff like namespaces, CDATA and friends. I still think XML is a horrible, misguided idea - from inception, but even more so in ho…

I think a big problem with XML in most languages is the tooling around it. The libraries to parse/create it are not very pleasant to work with because of the immense complexity they have to deal with. If they only had to conform to a very small subset of all of XML's features and quirks, you'd have a very sane ecosystem.

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

#139

Post by qwertyuiop924 » Sun, Jul 31, 2016, 10:21 PM UTC

edejong wrote: post #114

qwertyuiop924 wrote: post #75

Earlier quoted context omitted.

Okay, back to me: >Actually, quite a lot in the past! Back in 2009 I did some XProc pipelining of messages. These pipelines were a bit like reactive streams, which were (mostly) agnostic of the contents. This allowed me to combine, dissect and route streams of data in an intuitive way. Huh. So like this: |xmlstream|->|transformer|->|xmlstream| Pretty slick. So the namespacing allowed you to add new tags, without worr…

wrt the XProc pipelining: it's been some time, but I recall various possible transforming and matching steps, such as a conditional stream, transformers, reduction steps of multiple streams and others. This could then be combined with XPath, XQuery, XSLT and even SOAP requests. The problem of XProc was similar to the rest of the XML era: it required too much of the implementer to understand. Also, good programmer too…

Okay. Cool.

I wasn't just trying to flame when I wrote: Talking to people who have different ideas and use different stacks is a good idea, and it teaches you things you didn't know before. And learning about stuff is why I use HN in the first place :-).

>The problem of XProc was similar to the rest of the XML era: it required too much of the implementer to understand. Also, good programmer tooling, such as graph editors for the pipelines were missing.

I will have to look up XProc now, because the things you've been saying sound really interesting, and it's clear I don't really get it.

>But I agree, XML is definitely not the best data-interchange format, but neither is JSON. Some LISPy syntax would be my preference for data-interchange if it needs to be readable.

I suppose. I love lisp considerably more than the next guy, but lisp structures technically only specify linked lists, which are O(n) for all data retrival. This is also how most implementations implement them. Also, JSON is similar, and trival to convert to that format

  ["like", {"key":"this"}]
  =>("like" (("key" . "this")))

Although you would idiomatically use symbols in many places where JSON uses strings.

>XML Schema actually does spec binary data

Once again my inexperience with xml shows. Thanks for letting me know.

>With regard to round-trips: as a general rule it might not hold if you ask me. It implies an origin and even state![...] Personally, I like RESTful for simple systems, but for more involved architectures, message passing is much more scalable and easier to distribute.

Firstly, I'm pretty sure REST implies a message-passing architecture. Correct me if I'm wrong.

Secondly, the round-trip idea sucks for a number of reasons, but I don't think it has to imply either. Let's say you have an endpoint at example.com//lastmessage, which might give you the last message the user sent. If the user sent "just ate at Joes, #delicious," you might receive:

  {"message-type":"text", "message":"just ate at Joes, #delicious"}

But if the user sends an image, it's uploaded to the server, and you have to get it down. So you would instead get:

  {"message-type":"image", "message":"X57pqr32"}

And you would ask for example.com//static/X57pqr32.

I don't know, but I think that would work.

>But the weird thing is, of all our libraries and all our frameworks (browser-side), none of them do streaming.

And I actually know why this is: Before the advent of Websockets, the only API was either XHR, or awful ideas (JSONP should chill the blood of any security expert). None of them supported reading incrementally, AFAIK, so there was no point. Now that Websockets are a thing, it shouldn't be long coming. Now all we need to do is build something to put JSONP in the ground...

>But hey, there are so many metrics with which one can evaluate a data-interchange format. (Recently we did a survey of binary data-interchange formats and found around 25 different criteria... and we were not really being thorough).

Indeed. By the way, did you look at Cap'n Proto and MessagePack? Neither are really on the fringe, but they look interesting, and they seem to have some decent support.

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

#140

Post by zachrose » Sun, Jul 31, 2016, 10:28 PM UTC

nialo wrote: post #127

barrkel wrote: post #32

Earlier quoted context omitted.

The biggest problem with XML is that it's a node labeled tree that makes the schema choice between leaf node and attribute for scalar data almost arbitrary, whereas JSON is an edge labeled tree without the same choice. Most programming languages use edge labeled graphs for in memory data structures, so the semantic distance is lower with JSON.

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 is a paw.

This example is sort of a straw man. The JSON version could be wrapped with { "dog": {...} } and the individual XML paws could be wrapped in a element. But in any case, JSON doesn't need you to give an explicitly label the type of each paw, just what they belong to and what's known about them.