Elements and Tags

Elements (and tags)
So, how does all this markup work? Let’s closely examine some example XML markup to find out.
Recall that the core purpose of markup is to organize content into related pieces and identify them
explicitly. These pieces of content are grouped into sections, called elements. The start and end annotations
of elements are commonly referred to as tags.
An element is nothing more than text wrapped between a pair of tags. Angle brackets, the < and >
characters, delimit the beginning and end of a tag. Take for instance, this piece of text:
Where the Streets Have No Name
You might easily identify this text as a song title written by the band U2. However, someone else might
not be able to recognize this song title, so you need to indicate what it is in proper markup form. Well,
let’s label what it is and identify it as a title, like so:
<title>Where the Streets Have No Name
So, you’ve now identified where the title starts by annotating the beginning of the song title with the
<title> tag, but in XML, that’s not enough. You also have to identify where this title ends. To do that,
you simply use the same tag again and include a forward slash directly after the left angle bracket:
<title>Where the Streets Have No Name</title>

Now you have successfully marked up the title of this song by annotating its beginning and its end
explicitly using opening <title> and closing </title> tags. What you’ve created is a <title> element
that, in this case, is nothing more than the text of the song. In XML and all its specific
 applications—
including XHTML—all elements with any kind of content (either text or other elements) begin and end with a pair of tags like this.
Let’s add the artist information next so that readers of the XML document know what band wrote the song. All you have to do is mark up the text U2 as a similarly obvious element. Let’s call it <artist>
and add that directly after the title:
<title>Where the Streets Have No Name</title>
<artist>U2</artist>
You can continue adding information about the song in this way and include all sorts of information.
For instance, this song came out on the album titled The Joshua Tree in 1987. You can add that to your
list of information, marked up as follows:
<title>Where the Streets Have No Name</title>
<artist>U2</artist>
<album>The Joshua Tree</album>
<released>1987</released>
By now you have a good deal of information encoded in the XML document about this song. Let’s now
take this one step further and encode information about many songs in the same 
document. To do this, you need a way of grouping all the elements related to a 
single song together so you can clearly delineate where the information about one song
 ends and the next one begins.
In XML and most other markup languages, elements can be nested (placed inside 
one another) if the information can be grouped together in a meaningful way. So, you
 could take all the markup you have already defined for your single song and put it 
inside a <song> element, like this:
<song>
<title>Where the Streets Have No Name</title>
<artist>U2</artist>
<album>The Joshua Tree</album>
<released>1987</released>
</song>
Now, you have defined one <song> element in your document. Since that <song> element encloses four other elements, it is said to have four children and is itself called the parent element of those child elements.

You can see a common convention of an SGML-derived markup language here. Any element
that is nested inside another element is typically indented, and the enclosing
element’s start and end tags are on their own lines. This is done purely for ease of
reading and editing by humans. Software programs written to interpret this markup will
typically ignore all this whitespace between the tags (including the indentation, the line
breaks, and so on), as well as any extra whitespace inside elements or an element’s content,
so technically all these tags could be right next to each other and still be just as
meaningful. The browser simply interprets any number of consecutive spaces or tabs as
a single space. Nevertheless, it’s good practice to keep to this style of indentation since
it’s much easier to edit the markup when its structure is visually obvious.