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

121–130 of 255 posts

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

#121

Post by mwfunk »

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 binary blob rather than disappointment that it's not freeform text, because I assume that freeform text must've been off the table for whatever reason (which, depending on what the config file is for, can be a totally rational and reasonable thing to do).

I don't work in specialties where XML has a ton of visibility though- maybe there are lots of projects out there that I don't use in which people are required to hand-edit XML config files, as opposed to "it's in XML, so you could edit it directly, but really no one should be modifying the file with a text editor unless the preferred indirect mechanism isn't an option in some specific case".

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

#122

Post by throwaway_java »

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…

yeah. What kind of nut-bag edits config files using a text editor.

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

#123

Post by beagle3 »

DougN7 wrote: post #63
Nuffinatall wrote: post #53

Compared to the problems when dealing with 'delimited text', XML is great. Also it's flexible where you can specify properties as attributes or child nodes, depending on wildcard specifications. So I have dealt with lots of edge-case XML situations, but the solutions are always straight forward. Also it helps to have a client vs. trying to parse out raw XML, which means programming and scripting sometimes relies on p…

Handling scope creep is my favorite feature. With XML, it's easy to deserialize even if an expected element is not there, or if there is an extra one you're not expecting, at least that's been my experience. I haven't done much JSON but I'm not sure how that would work with it.

JSON deserialization would basically be the same. XML does not score here.

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

#124

Post by JoshTriplett »

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…

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-80da344efa6a
        2003-12-13T18:30:02Z
        Some text.
That said, I like S-expressions too, and I wish more parsers and tools existed for them, such as schemas, query tools, and simple transformation tools.

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

#125

Post by SomeCallMeTim »

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…

>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 to read than XML)

* Any of the above compressed with a gzip compatible compression (if size matters, though it rarely does these days)

Even Protocol Buffers [2] are better than XML, though at that point it becomes a "documented binary blob". But as long as the spec is shared, the format can easily be read by just about any programming language.

[0] https://en.wikipedia.org/wiki/YAML

[1] https://en.wikipedia.org/wiki/INF_file

[2] https://en.wikipedia.org/wiki/Protocol_Buffers

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

#126

Post by colejohnson66 »

oceanswave wrote: post #107
colejohnson66 wrote: post #101

Earlier quoted context omitted.

I've seen empty values written as data Whether that's legal or not, I don't know.

not valid. wondering if you've seen that within HTML, where it is valid.

Actually, now that you mention it, I think it's from Chrome's Inspect Element tool, but I can't check right now.

I think if you wrote something like

    ...
it would display in the tool as

    ...

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

#127

Post by nialo »

barrkel wrote: post #32
qwertyuiop924 wrote: post #21

Earlier quoted context omitted.

Well, XML is complicated, so it's hard to build support for, and it's verbose, so it's heavy on the wire. Frankly, I think JSON is a better format in most contexts.

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.

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

#129

Post by SomeCallMeTim »

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…

>well regarded in the enterprise

I think this alone should be enough to cast doubt on it, based on my (albeit limited) interactions with "enterprise" software.

>I think it's bad reputation comes from anyone not using an enterprise language because the support just isn't there.

What, like JavaScript? I've had to read and write XML packets from a Node app to work with (surprise!) an enterprise app. I had probably 20 choices of libraries with varying levels of features, and the one I chose worked fine.

I was lucky, compared to some of the others on this page: The "RPC"-style XML commands and responses I had to parse and generate were all well standardized, so I just wrote a wrapper that extracted the completely opaque tree of XML into a flatter JavaScript object/hash that was really easy to deal with, and similarly made a wrapper that would trivially generate the monstrous XML required to send commands and responses back to the server. My JSON-equivalent objects were easier to manipulate (and would also have been easier to deal with in Java or, in this case, C#), equally rich in the information they carried, but could have been serialized with 1/3 the number of bytes per message. Totally a win-win-win.

What I don't understand is why anyone thought using XML that way was a good idea, and why it still is popular in the enterprise. Bad habits are hard to break, I guess.

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

#130

Post by moron4hire »

mbrock wrote: post #59
moron4hire wrote: post #51

Earlier quoted context omitted.

> For me the only thing that JSON got better is that JSON is directly mapped to commonly used data structures: arrays and maps. This is nice, but it's also kind of a pain, as it makes you have to stop and think about which structured data elements it's capable of supporting and which you have to send your own metadata through the wire and then reconstruct on your own. For example: Dates. Which is a shame. If there is…

The XML tag style is much, much easier to work with when you're dealing with markup. And XML's purpose is to be an Extensible Markup Language. It's way more appropriate than JSON or S-expressions for that. (Do you prefer to write HTML documents as S-expressions?)

> The XML tag style is much, much easier to work with when you're dealing with markup.

Having explicit end tags makes it harder to make well-formed documents that don't clash their closing tags.

Consider a very typical sort of HTML error:
Interleaving tags is never correct, yet XML allows us to do it (and I've seen it happen a lot).

The comparable S-Expr shows how it is just plain impossible to interleave tags:

    (table
      (tr
        (td)))
You might ask yourself, "which close paren closes which list?" if the document were particularly gnarly. But if we're talking about particularly gnarly documents, then XML can be just as ambiguous. You'd be using a text editor that highlighted matching parens for you, at that point, just as much as you'd be using one that highlights matching close- and end-tags.
Post reply on HN