If computers are able to parse data organised in curly braces, why are we using <foo></foo> syntax in certain languages? Only because of legacy etc or are there further reasons behind this?

I think I speak for many people if I say that that looks just redundant and it's awkward to work with. In adition it doesn't "enforce" indentation like brace-based languages do.

Update - I made the mistake of treating curly braces and key-value pairs (which I didn't mention until now) as the same concept.

Taking into account this, I'd like to ask my question again: Is tag syntax really more convenient than a JSON-like language?

  • Why would you say brace-using languages enforce (even with the quotation marks) indentation?
    – pyvi
    Jul 13 '11 at 14:18
  • 1
    Without indentation, a highly nested block in a brace language would be just unreadable for an human, whereas with markup syntax it would be acceptable.
    – deprecated
    Jul 13 '11 at 14:29
  • 1
    @vemv, you've just given one reason for using markup languages ;-) Jul 13 '11 at 14:31
  • I disagree... I just find it a very little gain. Unindented markup code beats unindented brace code, okay, but an indented brace block beats everything.
    – deprecated
    Jul 13 '11 at 14:45
  • because its Markup one of the goal I think was to be human readable.
    – Darknight
    Jul 13 '11 at 16:03

Braces are usually used to indicate the begining and ending of a block. There's no semantics behind the brace, it is usually captured by some other nearby symbol such as while, if, etc... tags such as <foo></foo> indicate the begining and ending of the block and capture the semantics.

I suppose you could change tag-based markup from

<ns:foo attrib="test" attrib2="123/>
   some values and nested elements can go here


ns:foo(attrib="test" attrib2="123")
    some values and nested elements can go here

which still contains the semantics of the first example (we know that we are dealing with a foo element from the ns namespace and we have the element's attribute values) but in a different format.

Why markup is done with tags is as far as I can tell to make it easier to be read by humans. Scanning a sequence of closing }'s with eyes, it's easy to get lost as to what element is being closed. Fancy editors that highlight and keep track of what element your cursor is in can help, but you can't always garauntee you'll have this (such as when fixing an XML config file on a remote server using pico).

Basically, this:


Is easier to read than:


I've seen XML with elements nested > 10 levels deep (much more often than I ever see code nested like that), and when working with these files, knowing which elements is being closed really helps.

In response to your question update:

I am not a JSON expert but a quick google showed me some examples. JSON's key-value pairs look like a nicer alternative to single-valued items, such as <foo>some value</foo> but I still think that for deeply nested items, the issue of not knowing where you are on the screen is mitigated by having the closing tags.

An ideal, theortical, off-the-top-of-my-head combination, based on a wikipedia example:

     "firstName": "John",
     "lastName": "Smith",
     "age": 25,
         "streetAddress": "21 2nd Street",
         "city": "New York",
         "state": "NY",
         "postalCode": "10021"
           "type": "home",
           "number": "212 555-1234"
           "type": "fax",
           "number": "646 555-4567"

Of course, we could have done most of those key-value pairs as attributes, such as:

<person firstName="John"
         streetAddress="21 2nd Street ...>

I think this would be even cleaner than most JSON syntax, and simple elements could be done as

 <foo value="some value"/>
  • 1
    Indeed, markup languages are usually nested much more deeply than full programming languages.
    – Maxpm
    Jul 13 '11 at 15:02
  • Braces alone wouldn't improve readability that greatly, but in addition to key-value pairs (which I forgot to mention - my bad) they can generate very lightweight, readable blocks.
    – deprecated
    Jul 13 '11 at 15:23
  • 1
    @vemv: Well then, why not update your original question with your example of braces with key-value pairs because I'm not sure I understand what you mean... Jul 13 '11 at 15:29
  • @Frustrated: of course, one would say that XML is not meant to be read by humans... Jul 13 '11 at 17:26
  • @Matthieu M.: Whether or not it was meant to be, it happens often enough. ;) Jul 13 '11 at 17:32

A couple of reasons which come to my mind:

  • markup languages are meant to be read and processed by machines as well as (or even more than) for humans
  • opening and closing tags reduce the possibility of errors, and make recovery easier - redundancy is the price to pay for this, but in this era of cheap storage and bandwidth, many value error recovery higher than saving a few bytes
  • the tags provide context, which is priceless when e.g. document versions may change frequently
  • it also allows navigation within a document
  • Conforming XML processors are explicitly forbidden to return any content when they encounter any kind of error, so whatever the reason for the duplication of tags was, error recovery isn't it. Jul 13 '11 at 14:43
  • @Kilian, that's like saying that since cars are forbidden to break the local speed limit, the 5th/6th gear in many of them must have some purpose other than speeding up the car ;-) Jul 13 '11 at 14:50
  • It just shows XML is design-by-committee. The redundancy shows a "almost-right is perfectly usable" principle and the conformance requirement shows a "almost-right is entirely wrong" principle. Not a consistent design philosophy IMO.
    – MSalters
    Jul 14 '11 at 12:44

First of all, how would a brace-based markup language enforce indentation anymore than a tag-based one? Indentation, unless recognized by the parser (like in Python, YAML, or CoffeeScript) is largely a preference of the one writing the code.

Second of all, what kind of a syntax would you propose that would be so much more concise and readable? As FrustratedWithFormsDesigner noted, the ending </foo> is useful because it denotes what you are closing. If you've ever mucked around in C-based languages, you know what kind of confusion having


leads to. Sure, you can comment each ending brace with the block it belongs to, but then what's the difference between } //foo and </foo>? At least the parser knows what's wrong with the </foo>.

  • I used the "enforce" term with quotation marks... As for the example you gave, I personally wouldn't feel uncomfortable with it. Judging by the popularity of C-based languages, I bet many other people wouldn't, too.
    – deprecated
    Jul 13 '11 at 15:00
  • TBH, I don't particularly like the tag syntax either, but it is superb at what it does, and I don't know any better general (i.e. NOT a DSL like Markdown) markup syntax, or how it could be improved. Jul 13 '11 at 15:17
  • It has been already, via the key-value pairs - that's why JSON is much preferred over XML lately
    – deprecated
    Jul 13 '11 at 15:25
  • 2
    I meant something that could be a stand-in replacement for XML, duplicating the nested object and attribute functionality. JSON comes close, but is a data serialization format, not markup, whereas XML covers the ground of both. Consider the XML <a href="foo.com">foo</a> versus its (more or less) JSON equivalent: { "tagName": "a", "attributes": { "href": "foo.com" }, "childNodes": [], "textNode": "foo" } Jul 13 '11 at 16:10
  • @Austin Hyde: I would argue that things like attributes are a meaningless distinction. The JSON equivalent might be better written as: "a": { "href": "foo.com", "children": ["foo"] } with more complex cases like: "a": { "href": "foo.com", "children": ["foo", {"img":{"src":"/img.jpg"}} ] } Or even better: "a": [ {"href": "foo.com"}, {"text":"foo"} ] } S-expressions could be equally as terse.
    – greyfade
    Jul 13 '11 at 17:47

It's just another way of doing things. There are other languages that denote code blocks with keywords, like BASICs IF...ENDIF. Some, like Lisp, use parenthesis. Whatever delimiter a language uses is defined by the author's tastes and what he thought would be most appropriate.

The angle bracket syntax is generally used in markup languages. These languages have there roots in editors that used tags to apply formatting (markup) to your text. My guess is that the authors felt it was more readable to always close a markup block explicitly. In HTML, for example, a closing tag may be very far from it's opening tag, so seeing a "close body" tag can be easier to read than a brace.

As for indentation ... I'm surprised there hasn't been a bloody crusade over it yet. Well-formed XML does lend itself to good, readable indentation. Even more imperative XML formats, like ANT scripts, can be indented very naturally. Only one language that I know of (Python) enforces indentation. The others ignore anything more than a single space.


First of all, it's a matter of taste. There's no intrinsic advantage of 'brace languages'.

But, I think most important, is that SGML-based languages have two different use styles: structured data and marked documents.

For structured data, yes, indentation is a big help for readability, and sometimes a brace is welcomed because it's smaller, some other times, a tag is nicer because it tells the kind of block at both ends.

But it's on marked documents where indentation results less useful. Which is more readable?:

<p>This is a <strong>short</strong> paragraph, with only a <i>few</i> words.</p>


  This is a
  paragraph, with only a 
  • Good point on differentiating data from documents. For my taste, something like <strong>{short} instead <strong>short</strong> would be simpler.
    – deprecated
    Jul 13 '11 at 15:41

You can do the following transformation on well-formed html:

<foo>  --> (foo
</foo> --> )

(plus some string quoting) and your html becomes an s-expression, meaning your page can be processed by a lisp interpreter.

A while back I used a similar scheme to translate html to Tcl and then used an embedded interpreter to process web pages.




Using braces or brace-like characters for limits you to four different types of blocks ((...), [...], {...} and <...>) and would rule out other uses for those characters.

The current <foo> ... </foo> format you find in HTML and XML has its roots in Structured Generalized Markup Language, which has been around since the 1980s.

  • You can devise a syntax to escape the characters used for block begin/end.
    – Jay Elston
    Jul 16 '11 at 17:57

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.