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

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

hsivonen.fi

Post reply on HN
Print view View original

141–150 of 255 posts

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

#141

Post by brightball »

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…

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 generation. The number of JavaScript templating options out there are trying to fill the XSLT gap.

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

#142

Post by edejong »

beagle3 wrote: post #119
edejong wrote: post #62

Earlier quoted context omitted.

I've never really subscribed to the mindset of XML for it has many disadvantages (the verbosity, the complexity of DTD, the tendency for documents which are too large). However, I do subscribe to namespaces, since it allows global referencing of names. I also do subscribe to formal grammars, mature standards, and good documentation. FYI, I've designed streaming JSON based secure messaging systems, did binary-only sch…

> I do subscribe to namespaces, since it allows global referencing of names I have been forced to use XML one way or another for a variety of uses (mostly integration, not document storage - but still), and have not ONCE had a use for namespaces or multiple DTDs in a single document. I suspect no one has statistics, but I wouldn't be surprised if this is true for 99.9% of {users,documents,systems} - which, if true, m…

> and have not ONCE had a use for namespaces or multiple DTDs in a single document.

I'm actually rather surprised about that. Take an XSLT document and you're bound to use multiple namespaces. Have you never used an editor which provides tab-completion, quick validation and documentation of tags on the fly? The systems I worked with heavily relied on namespaces for validation, exploration, versioning and prevention of naming clashes. These, however, were heavily distributed systems within government organisations.

Also, please note I'm talking about namespaces within and outside XML. I'm saying that namespaces are a cheap and easy to implement design rule.

Ok, now your references.

[0] is actually an argument for namespaces (and XML schema or suchlike). If I understand correctly, he proposes a system which allows you to specify part of an XML document post-hoc (using a namespace which references a schema which is specific to the module-writer).

The second one, I must admit that for me it had a low signal-to-noise ratio. The writing seems to refer only to XML and DTD, but nothing about larger ecosystem, which my arguments were about. Anyways, remove all the banter and you're left with a couple of arguments:

1. the syntax is verbose (yes it is, nobody disagrees, not even the designers).

2. there is no macro support (perhaps useful, one could embed an XSLT stylesheet if necessary). I find this a minor point. It would also severely complicate the parsers and make them stateful and memory-bound.

3. binary representation (in line with 1). How many good, portable binary structured editors do you know? How much does the size of an XML document improve with simple compression to binary? (hint, quite a lot). Also, when going to binary, there are many other design choices, such as: should it be possible to memory-map the document so the CPU is not involved? Should pointers be employed so we can skip sections of the document? Should we use names, ids, UUIDs? Do we optimize for processing use, network use, memory use? [1] seems to only argue about network utilization (which, for most applications, is abundant).

The rest of the document (I have to admit, I skimmed some parts), appears to be a rant on everything and everyone stupid. The king who shouts: "I am the king!", is no true king.

> If it does know [the namespaces], they don't matter either.

To structure something, we first need to construct, e.g. bring together and later we need to deconstruct. In both cases, it helps to have namespaces because (de)constructing might involve many different distributed parties, with different versions of software. It is my opinion that in truly distributed systems, naming and typing are of utmost importance.

It's getting quite late here. Thanks for making me think about this subject again. Sadly I cannot answer all of your points within a reasonable time.

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

#143

Post by PeterisP »

wtbob wrote: post #117
legulere wrote: post #102

Earlier quoted context omitted.

The problem is that XML maps badly to data structures in common programming languages. JSON maps perfectly to structs and datastructures as lists/arrays/maps. S-expressions are good if you work with Lisp like languages, but I don't think they're very readable if you're not into Lisp. I also can't see how they map easily into datastructures of imperative programming languages or even statically typed functional progra…

> S-expressions are good if you work with Lisp like languages, but I don't think they're very readable if you're not into Lisp. Take a look at https://news.ycombinator.com/item?id=12198581 ; I think it demonstrates how readable one dialect of S-expressions can be. > I also can't see how they map easily into datastructures of imperative programming languages JSON consists of numbers, strings, booleans, objects and arr…

There is a very big difference - "with JSON one still must check the expected types anyway" is not really true, I can deserialize an arbitrary json and I will know the difference between 123 and "123" even if I don't know what's expected or, alternatively, mixed-type values are expected.

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

#144

Post by zyxley »

wtbob wrote: post #117
legulere wrote: post #102

Earlier quoted context omitted.

The problem is that XML maps badly to data structures in common programming languages. JSON maps perfectly to structs and datastructures as lists/arrays/maps. S-expressions are good if you work with Lisp like languages, but I don't think they're very readable if you're not into Lisp. I also can't see how they map easily into datastructures of imperative programming languages or even statically typed functional progra…

> S-expressions are good if you work with Lisp like languages, but I don't think they're very readable if you're not into Lisp. Take a look at https://news.ycombinator.com/item?id=12198581 ; I think it demonstrates how readable one dialect of S-expressions can be. > I also can't see how they map easily into datastructures of imperative programming languages JSON consists of numbers, strings, booleans, objects and arr…

You could do make it more like S-expressions in JS if you really wanted.

    {object: [
      {id: "1234"},
      {isEnabled: "true"},
      {props: ["abc", "123", "false"]}]}
Not quite the same, but nothing keeps you from parsing an array of key/value pairs instead of a hash.

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

#145

Post by voltagex_ »

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…

Microsoft pretty much standardised on XML all through the early .NET framework - app.config and web.config, plus most project files are XML files, and defining your own configuration (past simple key/values) is very tricky and error-prone.

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

#147

Post by lttlrck »

einhverfr wrote: post #25
Freak_NL wrote: post #19

Earlier quoted context omitted.

It's a classic trap that appears to get software developers caught (even now in 2016!) at that point where you are still lacking that firm grasp of the standard libraries available to you.

Yep. As I usually say, it is better to be able to say "not my problem" than it is to be able to say "invented here." The single greatest strength of a skilled software engineer is to know when to make it someone else's problem.

Even if it is not your fault it can still be your problem.

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

#148

Post by flukus »

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…

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

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

#149

Post by erlehmann_ »

wtbob wrote: post #115
JoshTriplett wrote: post #108

Earlier quoted context omitted.

> I think that XML's bad reputation comes from the fact that it is so incredibly verbose . > Also, the whole child/attribute dichotomy is a huge, huge mistake. Those two factors run counter to each other. Attributes decrease verbosity, compared to child elements. I agree, though. A few changes would make XML closer to ideal: eliminate attributes and eliminate the name in closing tags ( value ), which makes child elem…

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

The second and third examples do not have namespaces.

How would you include an HTML summary, for example?

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

#150

Post by WatchDog »

bane wrote: post #131
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…

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…

Spring was certainly a very XML focused framework.

However it has had for a long time ways of using property files in conjunction with XML, while you would still need the XML to define your dependencies, you could have a simple property file for runtime configuration.

Thankfully in newer releases and with spring-boot you can avoid XML entirely.

Post reply on HN