THE XML SPECIFICATION GUIDE

Errata for Chapter 3, Part 2

Page 171, Appropriate coding for "empty" elements (bottom of page)

The explanation is a bit unclear here -- the following more detailed discussion should help clear things up.

The markup <myElement /> and <myElement></myElement> both correspond to an 'empty' element, so that these representations can in principle be used interchangeably whenever an element instance has no content. However, 'for interoperability' (with older SGML processors), the 'empty element' form should _only_ be used if there is a document type declaration, and if this formally states that myElement is empty:

<!ELEMENT myElement EMPTY > 

This is because most SGML-only tools won't understand the empty-element notation, and will look for an end tag for every start tag unless the DTD explicitly denotes the element as empty (most SGML processors simply ignore the trailing / in the empty element tags).

"Pure" XML tools are far more forgiving, so that any element instance that happens to be empty can be written as an empty-element tag. Thus, the following is entirely well-formed XML:

<myElement src="http://www.foo.org" />
<myElement src="http://www.foo.org"></myElement> 
<myElement> here is an element with content </myElement>

This may or may not be valid, of course, depending on constraints implied by the DTD (if there is one).

As a convention, it seems reasonable to use 'empty-element' tags to denote elements that must always be empty, since this notation makes it less likely that someone would 'accidentally' put content in an EMPTY element. But this is only a convention, and it has both advantages and disadvantages - the disadvantages lying in the handling of this data by older software.

Also, it is important to note that the canonical XML specification "canonicalizes" empty elements by converting them to a start-tag/end-tag pair.

Update to:

Chapter 3
Part Two

Wiley Home

Ian's Home
Liam's Home