If this is all there is to XML, what makes it so powerful and so widely used?
XML itself is just a foundation, and on that foundation a lot of buildings have been, are being, and undoubtedly will be erected. You won’t believe how many valuable programmer resources were wasted before the advent of XML on inventing new data formats for each application, formulating their rules, writing and testing software to support them, and working around the inevitable bugs, exceptions, and version incompatibilities.
All this misery is now a thing of the past. Now, if you need to record some data, you don’t need to go into the low-level details of which characters have special meanings and what are the sizes of various fields. By choosing XML (and you would need serious reasons not to choose it) you can concentrate on things that really matter: the structure of your data and how to name elements and attributes that would best express that structure.
Moreover, these days it is quite likely that you won’t even need that, because a well-known standardized XML vocabulary for your data probably already exists, and you can just make use of it. Each vocabulary defines a set of elements and attributes, detailing what they are supposed to mean, in what contexts they may or may not be used, what is obligatory and what is optional, and so on. SVG is one such vocabulary; XHTML is another. There exist standardized XML vocabularies for a lot of exotic things, from dog genealogies to star catalogs. Many of them reuse parts of other vocabularies.
To be able to mix parts of different vocabularies without confusion, XML uses namespaces. A namespace is just a way to indicate where a specific element or attribute comes from. For example, here’s an image element from SVG vocabulary, representing a linked bitmap image inside an SVG document:
<svg:image xlink:href="/dir/file.png" width="200" height="100"/>
You can see that the element name and one of the attributes use a colon (:). The part of the name before the colon is called the namespace prefix. To find out which namespace corresponds with which prefix, we must look for a namespace declaration in the form of a special xmlns prefixed attribute (short for XML NameSpace), either on the same element or on any of its ancestor elements up the tree. It is customary to place all namespace declaration attributes on the root element. In this case, you will likely find the declarations for svg and xlink prefixes in the root svg element:
<svg:svg ...
xmlns:svg="http://www.w3.org/2000/svg"
xmlns:xlink="http://www.w3.org/1999/xlink"
... >This means that the svg prefix is bound to the namespace of http://www.w3.org/2000/svg and the xlink prefix corresponds to http://www.w3.org/1999/xlink. Here, the namespaces are URLs, but they need not be; the only requirement is that they must be globally unique (and URLs are just the easiest way to ensure this uniqueness).
The namespace URL for SVG, http://www.w3.org/2000/svg, must look exactly as shown. If the namespace prefix of the elements in your SVG document does not resolve to http://www.w3.org/2000/svg, neither Inkscape nor any other software will recognize the document as SVG. The namespace prefix, however, may be arbitrary, so long as it’s bound to the correct namespace. The prefix may even be empty if you declare it thus:
<svg ...
xmlns="http://www.w3.org/2000/svg"
... >Inside the element with that declaration, any element name without a prefix will be assumed to be in the SVG namespace. For example, the following will be recognized as a valid image element from SVG, which links an external image file in PNG format:
<image xlink:href="/dir/portrait.png" width="200" height="100"/>
Namespace errors, such as no namespace declared for a prefix or a wrong namespace URL, are most common when you edit your SVG by hand and then try to load it into Inkscape. Watch out for them!