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

191–200 of 255 posts

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

#191

Post by thom »

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.

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

#192

Post by mbrock »

wtbob wrote: post #120
mbrock wrote: post #59

Earlier quoted context omitted.

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?)

> Do you prefer to write HTML documents as S-expressions? Actually, yes. I use CL-WHO[1] a lot, in which one can write: (:html (:head (:title "Foo bar") (:link :rel "stylesheet" :href="baz.css")) (:body (:p "Lorem ipsum dolor sit amet, consectetur adipiscing elit. Vestibulum ullamcorper efficitur purus, at suscipit nunc luctus vitae.") (:ol (:li "Cras vel est accumsan, malesuada leo eu, iaculis nulla.") (:li "Proin n…

I like S-expressions too, especially when generating markup programmatically. For hand-writing HTML/XML documents, which I do quite a lot, I really enjoy the tag style because of the verbose end tags and the ease of moving blocks. It's at least nice enough to make me annoyed when people claim the tag syntax is some horrible stupid disaster compared to S-expressions or (worse) JSON.

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

#193

Post by mbrock »

moron4hire wrote: post #130
mbrock wrote: post #59

Earlier quoted context omitted.

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

I've never had trouble with that.

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

#194

Post by zamalek »

brightball wrote: post #141
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 ge…

It's also that it's extensible (primarily because of namespaces) - you can mix and match schemas so long as one of them uses xs:any. This brings up another way to avoid being called a bozo: namespace your XML. You're throwing a major advantage away if you don't, and if you don't need/understand that advantage then you're better off using a different serialization format.

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

#195

Post by vbezhenar »

moron4hire wrote: post #130
mbrock wrote: post #59

Earlier quoted context omitted.

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

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

#196

Post by mbrock »

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.

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.

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

#197

Post by wtbob »

mbrock wrote: post #192
wtbob wrote: post #120

Earlier quoted context omitted.

> Do you prefer to write HTML documents as S-expressions? Actually, yes. I use CL-WHO[1] a lot, in which one can write: (:html (:head (:title "Foo bar") (:link :rel "stylesheet" :href="baz.css")) (:body (:p "Lorem ipsum dolor sit amet, consectetur adipiscing elit. Vestibulum ullamcorper efficitur purus, at suscipit nunc luctus vitae.") (:ol (:li "Cras vel est accumsan, malesuada leo eu, iaculis nulla.") (:li "Proin n…

I like S-expressions too, especially when generating markup programmatically. For hand-writing HTML/XML documents, which I do quite a lot, I really enjoy the tag style because of the verbose end tags and the ease of moving blocks. It's at least nice enough to make me annoyed when people claim the tag syntax is some horrible stupid disaster compared to S-expressions or (worse) JSON.

> For hand-writing HTML/XML documents, which I do quite a lot, I really enjoy the tag style because of the verbose end tags and the ease of moving blocks.

I can't say anything about liking verbose tags, which seems to me a matter of taste, but moving around S-expression blocks is easy: C-SPC to set the point, M-C-f to move forward one S-expression, C-w to cut the current region, navigate to where one wants it, C-y to yank the cut region.

Granted, this is using emacs, which really had better have good S-expression-editing capabilities after 40 years!

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

#198

Post by maze-le »

Some XML dialects become very confusing if features are added as an afterthought without consideration of syntax and sematics. Microsofts Wordprocessing XML for example has caveats like w:permStart:

    
    (...)
permStart and permEnd define regions where special permissions are required to edit a document. It is encoded in a complete anti-XML syntax, where different tags (and a common ID) represent the start and end of a region.

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

#199

Post by Perseids »

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.

JSON5 [1] is an extension to JSON that allows comments, multi line strings, additional commas at the ends of lists, and more. It has become my preferred config file format.

[1] http://json5.org/

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

#200

Post by lmm »

voltagex_ wrote: post #160
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…

How would you write that example while taking advantage of the XML features you're talking about?

Well this reduces to something like:

    
      blah blah
      this is the attribute value
The point is not to write a flexible meta-format for expressing arbitrary objects, because XML is already that. Each specific thing you want to express should have its own specific format. That way you can actually use the validation features too.
Post reply on HN