XML/HTML: Do we need the element name in closing tags?

Question

Compared to other serialization languages, one of the main criticisms directed at XML is its verbosity; JSON's more terse and readable for most cases, but not all.

But it seems to me that we could cut a lot of the excess from XML simply by stripping away the names from the closing tags. With proper indentation readability shouldn't be an issue (it should be an improvement, if you ask me), and since they're not structurally required any decent XML editor/viewer could easily be made to strip/hide or add them. As such, the two formats should be completely equivalent and interchangeable.

Compare the following (source taken from http://www.w3schools.com/xml/simple.xml):

<breakfast_menu>
    <food>
        <name>Belgian Waffles</name>
        <price>$5.95</price>
        <description>
                    Two of our famous Belgian Waffles with plenty of real maple syrup
        </description>
        <calories>650</calories>
    </food>
    <food>
        <name>Strawberry Belgian Waffles</name>
        <price>$7.95</price>
        <description>
                    Light Belgian waffles covered with strawberries and whipped cream
        </description>
        <calories>900</calories>
    </food>
    <food>
        <name>Berry-Berry Belgian Waffles</name>
        <price>$8.95</price>
        <description>
                    Light Belgian waffles covered with an assortment of fresh berries and whipped cream
        </description>
        <calories>900</calories>
    </food>
    <food>
        <name>French Toast</name>
        <price>$4.50</price>
        <description>
                    Thick slices made from our homemade sourdough bread
        </description>
        <calories>600</calories>
    </food>
    <food>
        <name>Homestyle Breakfast</name>
        <price>$6.95</price>
        <description>
                    Two eggs, bacon or sausage, toast, and our ever-popular hash browns
        </description>
        <calories>950</calories>
    </food>
</breakfast_menu>

and

<breakfast_menu>
    <food>
        <name>Belgian Waffles</>
        <price>$5.95</>
        <description>
                        Two of our famous Belgian Waffles with plenty of real maple syrup
        </>
        <calories>650</>
    </>
    <food>
        <name>Strawberry Belgian Waffles</>
        <price>$7.95</>
        <description>
                        Light Belgian waffles covered with strawberries and whipped cream
        </>
        <calories>900</>
    </>
    <food>
        <name>Berry-Berry Belgian Waffles</>
        <price>$8.95</>
        <description>
                        Light Belgian waffles covered with an assortment of fresh berries and whipped cream
        </>
        <calories>900</>
    </>
    <food>
        <name>French Toast</>
        <price>$4.50</>
        <description>
                        Thick slices made from our homemade sourdough bread
        </>
        <calories>600</>
    </>
    <food>
        <name>Homestyle Breakfast</>
        <price>$6.95</>
        <description>
                        Two eggs, bacon or sausage, toast, and our ever-popular hash browns
        </>
        <calories>950</>
    </>
</>

Answer 1

Can we change XML format (i.e. create a new language which doesn't have the verbosity issue)? Yes, we can.

In order to completely migrate to the "better XML" (let's call it BETXML), it would require to:

• Reimplement all the parsers,

• Rewrite all applications which currently use XML,

• Rewrite all protocols based on XML.

Or we can keep everything in place, and just invent a new language and wait until it starts to be adapted everywhere. The only issue is that benefits of a new language are very limited. Applications which require less verbose language already use JSON. How would you convince people that BETXML is superior to XML and JSON?

Answer 2

I fail to see the big gain with the </> variant. Are you talking about readability for the human eye? In that case I would take ordinary XML any day rather than trying to figure out what the code is trying to tell me when I see something like this in the middle of a file:

    ...
    </></></></></></></>
    <something>
    ...

An XML file is a data container. Just because you can read and edit it by hand in a text editor does not necessarily mean that it is a good idea to do so. It is primarily meant to convey data from one application to another (or, yes, to just store data).

So maybe you mean the actual file size? Well, if that is so important, then you are probably not using the most suitable file format anyway.

But a more important reason for keeping XML as it is, is that when there is a structural error in a real XML file, the tag/end-tag design of XML makes it very easy for a parser to determine where the problem lies, and thereby to determine if the rest of the file can still be used.

If there is an end tag missing in your </> variant, it is much more difficult for the parser find the cause of the problem. And if you do not have a good DTD, then the parser will not even see that anything is wrong until it reaches the end of the file and (hopefully) detects that there is a level imbalance. And at that point there is nothing to do but to reject the whole file since there is no way of telling where the error is.

Answer 3

We don't need it.

Your proposal would work just fine. In fact you can propose to the world your own extension of XML, let's call it XMLight, which is exactly the same except closing tags can be nameless and are meant to implicitly close the last opened tag.

Similar to Kotlin to Java, XMLight can be 'compiled down' to XML without loss of information or structure. Contrary to what is said in the other answer, this wouldn't be too disruptive as long as you provide the necessary tooling to compile it down as required by legacy systems.

That being said, you'd lose a key feature: robustness.

Let's take this broken XML as an example:

<outer>
  <middle id="A">
    <inner>content1</inner>
    <inner>content2
  </middle>
  <middle id="B">
    <inner>content3</inner>
    <inner>content4</inner>
  </middle>
</outer>

It is quite obvious what is wrong with it to the human eye, and very importantly too, to a computer. They can auto-format like this for you, and show you the error as being a missing closing tag to inner content2.

With XMLight, though, not so much:

<outer>
  <middle id="A">
    <inner>content1</>
    <inner>content2
  </>     <!-- This is really ambiguous! -->
  <middle id="B">
    <inner>content3</>
    <inner>content4</>
  </>
</>

There are plenty of possible interpretation of the imbalanced closing tags </> count and what the degraded XML shape should look like but most greedy parsers will get it wrong:

• missing <outer> closing tag, now <middle id="B"> and the entire rest of the document is considered nested inside A (most likely answer)

  <outer>
    <middle id="A">
      <inner>content1</>
      <inner>content2</>
      <middle id="B">
        <inner>content3</>
        <inner>content4</>
      </>
    </>
  <!-- missing closing outer tag reported here-->
  

• missing inner content1 closing tag (correct answer, would need a very smart parser or an xsd)

  <outer>
    <middle id="A">
      <inner>content1</>
      <inner>content <!-- missing closing inner tag reported here-->
    </>
    <middle id="B">
      <inner>content3</>
      <inner>content4</>
    </>
  </>
  

• missing inner content3 closing tag:

  <outer>
    <middle id="A">
      <inner>content1</>
      <inner>content2</>
      <middle id="B">
        <inner>content3<!-- missing closing tag indicated here-->
      </>
      <inner>content4</>
    </>
  </>
  

And so on...

For large XMLight potentially having multiple such errors, the possibilities are endless and probably would be presented in a very confusing way, also completely preventing the no-loss compilation back to proper (but faulty) XML!

Even in the best-case scenario where you have the xsd and know the nesting to be outer/middle/inner, your down compiling wouldn't be able to tell between missing <inner>content2 or <middle id="B"> closing tags. It would have to fail, or arbitrarily chose, meaning results would depend on implementation (ugh)