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

211–220 of 255 posts

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

#211

Post by erlehmann_ »

lmm wrote: post #209
erlehmann_ wrote: post #206

Earlier quoted context omitted.

Example: The XSLT stylesheet for this Atom feed generates a web page for each entry: http://news.dieweltistgarnichtso.net/notes/index.xml In this setup, the Atom XML for each entry is generated from XHTML with XSLT, which makes it possible to automatically include an Atom enclosure element for every XHTML media element. To publish a podcast episode, it is enough to add a post with an or element, as an XSLT stylesheet…

> Example: The XSLT stylesheet for this Atom feed generates a web page for each entry: http://news.dieweltistgarnichtso.net/notes/index.xml > In this setup, the Atom XML for each entry is generated from XHTML with XSLT, which makes it possible to automatically include an Atom enclosure element for every XHTML media element. To publish a podcast episode, it is enough to add a post with an or element. Sure. Why do you…

XML without namespaces does not exist. If it existed, how would you differentiate between title and link elements in Atom and title and link elements in XHTML? They have the same element names, but do not have the same meaning and therefore must be processed differently. Namespaces ensure that any XML processor can know the language of each part of the input.

Namespaces actually are the general mechanism with which you can specify that content is in another language: If you look at the feed source code, you can see that XHTML content is started with " rel="nofollow">http://www.w3.org/1999/xhtml"> and ends where that div element is closed.

Having an element with the semantics that “this content is in another language” is done out of necessity in HTML, as it has no namespacing: elements contain CSS, elements contain JavaScript, elements contain SVG … having an element in each language to embed each other language would become complicated very fast.

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

#212

Post by chii »

HelloNurse wrote: post #210
int_handler wrote: post #172

Earlier quoted context omitted.

My impression is that the reason why XML is so well-regarded in the enterprise is because these companies are not aware of better alternatives, such as Protocol Buffers [1]. The reason why XML has a bad reputation outside of the enterprise is because it is so incredibly verbose (both the language itself and the code used for working with it), and that all-in-all, it is a sub-optimal solution to a solved problem. To i…

Protocol Buffers are just one of many proprietary serialization libraries. Regardless of technical excellence, Protocol Buffers and competing libraries are automatically much less suitable for actual enterprise use than open standard serialization protocols with multiple interoperable implementations, such as ASN.1. And of course, XML is usually preferable to ASN.1 or the like because it is equally standardized but i…

Protocol buffer isn't proprietary. It's just not a standards based protocol. But it doesn't stop you from writing code against it, and you can easily interop with a third party who is using protocol buffers.

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

#213

Post by crdoconnor »

chriswarbo wrote: post #207
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…

I've always considered YAML to be far too complicated. There are many overlapping/redundant syntax rules for doing the same thing, lots of ways to mess up parsing, etc.

True, but if you turn those "features" off and swap out implicit typing for explicit typing it becomes a much simpler language.

This is what I ended up doing:

https://github.com/crdoconnor/strictyaml

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

#214

Post by moron4hire »

vbezhenar wrote: post #195
moron4hire wrote: post #130

Earlier quoted context omitted.

> 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: (tab…

This is not correct XML, parser will throw error. This is not correct HTML either. The only reason why this code is likely to produce good enough output in browser is that browser tries really hard to produce something readable even from complete garbage.

Yes, I know it's not valid XML If you had read my post and not just skimmed the examples, you would have seen that was the point. XML's verbose end-tag feature makes it possible to make malformed documents in such a way that is just plain impossible with S-Expressions.

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

#215

Post by moron4hire »

mbrock wrote: post #196
vbezhenar wrote: post #195

Earlier quoted context omitted.

This is not correct XML, parser will throw error. This is not correct HTML either. The only reason why this code is likely to produce good enough output in browser is that browser tries really hard to produce something readable even from complete garbage.

Such interleavings can actually be valid HTML5, in that the specification defines an algorithm for parsing that handles such "tag soup" in a reasonable way.

That's not the same thing as making interleaving valid.

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

#216

Post by [deleted] »

mbrock wrote: post #193
moron4hire wrote: post #130

Earlier quoted context omitted.

> 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: (tab…

I've never had trouble with that.

[deleted]

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

#217

Post by erlehmann_ »

lmm wrote: post #201
erlehmann_ wrote: post #188

Earlier quoted context omitted.

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?

It happens with any tree structure. E.g. I used to work on a system that managed reinsurance contracts and represented them as trees of contracts.

Did the elements often have immediate child elements that had immediate child elements (and so on) of the same type? Like:

   […]

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

#218

Post by chme »

thom wrote: post #191
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…

Here is an event from a popular sports data provider's XML format, for your delectation: XML and CSV, together at last.

Reminds me of the beautiful paths in svg:

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

#219

Post by Mikhail_Edoshin »

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…

Config files are usually plain key-value pairs and, of course, using a whole eXtensible Markup Language for them is kind of overkill. But if your config files are more complex, say, you need a Makefile-like stuff, then XML is more than appropriate.

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

#220

Post by chme »

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…

I am missing a config file format / parser&generator lib that preserves every comment and format (empty lines, etc.) after a read/write cycle.
Post reply on HN