This is a rather idiosyncratic beginners guide to XML that I wrote while living in Guernsey. Guernsey is a smallish island (population 60,000) in the channel between Britain and France. It has its own government and tax laws, and is in many respects, a small independent country. The island is divided into 8 parishes- one of which is a small town.
One of the ways that we mentally organize the world is to arrange things in hierarchies. For example when thinking of a place such as Guernsey, one obvious geographical hierarchy is the Island/Parish/Street view:
 |
Fig 1. An incomplete hierarchical description of Guernsey
Of course this is not the only way of thinking about the island, the Post office has divided the island into postal codes, and others have other ways of thinking about the structure of the place.
XML has been defined as a way of capturing all of these possible hierarchies in a form that can be understood by a computer. However it has been designed so that the same structure can be read and understood by a human as well. This is a change from the past when computer data has been stored in a format that only computers can make use of. For an example of the old way of doing the job you can try looking at the contents of a Microsoft Office document with a PC program like Notepad; it simply does not make any sense. To really understand and make use of an Office document you need to use the Microsoft Office software as well. XML files are different in that they can be examined and updated with the most basic tools, and that the XML format does not belong to a company. It is controlled by an international working group called W3C.
To dive right in to an example of XML, we could represent the figure above in XML as follows:
<?xml version = "1.0" ?>
<island>Guernsey
<parish>St Peter Port
<street>High St.</street>
<street>Bordage</street
<street>La Pollet</street>
</parish>
<parish>St Sampsons</parish>
<parish>St Andrews</parish>
<parish>St Pierre du Bois</parish>
<parish>Forest</parish>
<parish>Catel</parish>
<parish>Vale</parish>
<parish>St Martins</parish>
</island>
Fig 2. Guernsey as an XML file
If you have ever looked at the source of an HTML file on the Internet this code will seem very familiar, and there is a close connection between HTML and XML, in computer terms they are cousins.
If you look at the XML file in figure 2 closely you will see there is actually two kinds of text there. Some of the text is contained within '<' and '>', angle brackets. Some of the text is not. The text with angle brackets has a technical name, it is called a Tag. Thus the '<island>' is a tag and so is '<parish>' but 'Catel' is not a tag.
There are actually two sorts of tag in this file as well, tags that begin with a simple '<' are called Start Tags, and tags that begin with '</'are called End Tags. They usually travel in pairs, for every start tag in the file such as <island> there is and end tag </island>. The idea is that everything between the start tag and the end tag is part of an island, Guernsey in this case. In the same way, everything between <parish> and </parish> is part of a parish, and everything between <street> and </street> is part of a street. There is also a very odd looking tag at the top of the file:
<?xml version = "1.0" ?>
This is the line that tells us (and the computer) that this is an XML file, and it has been defined this way by W3C to let us distinguish XML from other file formats.
Introducing Attributes
Quite often we want to introduce more detailed information into an XML file, and this is often done using Attributes. An attribute is a small chunk of information that is associated with a start tag. For example, if we wanted to describe a car in XML we might find it convenient to talk about its model and colour:
<?xml version = "1.0" ?> <car model = "Volvo" colour = "white"> <owner>Andy Dwelly</owner> </car>
Fig 3. An XML description of a car
Both the model and the colour have been stored as attributes in the car start tag. You might wonder why the description of the owner was not stored in the same way. Sometimes this is simply a matter of taste when you are designing XML files, sometimes you have to do it this way. In the case of a car description, we can think of cars that have more than one owner. For example, the car in figure three really has two owners. It should really be described as:
<?xml version = "1.0" ?> <car model = "Volvo" colour = "white"> <owner>Andy Dwelly</owner> <owner>Marit Dwelly</owner> </car>
Fig 4. A more accurate XML description of a car
One of the important rules about attributes is that they can not be repeated, a car can not be both a Volvo 801 and a BMW 35i for example. A properly constructed XML file can not contain a tag like:
<car model = "Volvo 801" model = "BMW 35i" colour = "white">
A computer program that was presented with a start tag like this should complain. As a result of tags and attributes there are actually three ways of carrying information in an XML file. The tags themselves carry information by their very presence; the attributes and the text content between tags hold the rest.
One situation that you occasionally see is that attributes carry so much information that the text is not really required. For example, if we planned to store somebody's resume as an XML file, we could construct something like:
<?xml version = "1.0" ?> <resume name = "Andy Dwelly" tel = "721355"> <skill type = "XML"></skill> <skill type = "Plumbing"></skill> <skill type = "Driving"></skill> </resume>
Fig 5. Somebody with three skills
The resume start tag contains the person's name and telephone number as attributes, and then there are a set of skill tags, one for each skill the person has. Because the skill start tag contains all the details needed, there is no requirement for any extra text between the start tag <skill> and the end tag </skill>. When this happens, we can say that the skill tag is an empty tag and there's an abbreviation that can be used for this:
<?xml version = "1.0" ?> <resume name = "Andy Dwelly" tel = "721355"> <skill type = "XML"/> <skill type = "Plumbing"/> <skill type = "Driving"/> </resume>
Fig 6. Empty tag abbreviation
Since the skill tag is an empty tag, it can be rewritten with a trailing / before the final > as in figure 5.
This chapter has introduced several new ideas about XML files, start and end tags, attributes, and empty tags. It has also shown several examples of XML files that represent information that we could conceivably want to store in a computer. XML files are written so that they have a meaning to humans as well as to computers, and so that they can be constructed with basic tools like the Notepad program found on PCs.
The reason that we are interested in XML for Webflow is that it is used to create a script that controls the look and behaviour of the Webflow client.
Document Types
XML is a file format that is readable by people and computers. The previous chapter introduced several examples of XML files to store information about a place (Fig. 2), a car (Figs 3 and 4), and a person (Fig 5 and Fig 6).
However, people and computers deal with information in radically different ways. A person could look at an example of a resume file such as:
<?xml version = "1.0" ?> <resume name = "Peter Jones" tel = "976765"> <skill type = "Cooking"/> <skill type = "Driving"/> </resume>
Fig 7. Some information about Peter Jones
...and develop some sort of idea about the individual called Peter Jones. However when faced with an example like:
<?xml version = "1.0" ?>
<resume name = "Mr. Myxpllttt" tel = "999999">
<parish>
<skill type = "Green dreams in flying machines"/>
</parish>
</resume>
Fig 8. Some nonsense about Mr. Myxpllttt
... we could only say that this file was nonsense, it does not actually mean anything to us at all.
A computer works in a different way; they have no built in pre-conceptions about places, cars, people and so on. What a computer concentrates on is whether or not a file is correctly structured. Thus as far as a computer is concerned both files are equally correct because both files are properly structured. This dichotomy between the way that humans and the way that computers deal with the world is the source of much of the problems that we have when dealing with computers.
To show one final example:
<?xml version = "1.0" ?> <resume name = "Mary Davidson" tel = "786544"> <skill type = 'Driving'/> <skill type = 'Typing'> </resume>
Fig 9. Some information about Mary Davidson
This is an example that a person can understand but a computer can not. Can you spot the problem ? - the final / is missing from the second skill tag.
Much of the art of constructing XML files is to arrange matters so that both the meaning of the file in the human sense and the structure of the file in the computer sense actually coincide. In other words we really need to prevent examples like Fig. 8 which would be permitted by the computer but are simply rubbish as far as we are concerned.
We need a way to state what tags are allowed, and where they can appear. This is the job of the Document Type Definition which is usually known by it's acronym a DTD.
DTDs can be a little bit involved so I'm only going to give them the briefest coverage here.
DTDs are described using (amongst other things) element descriptions. We could write part of the DTD for the various resume files as:
<!ELEMENT resume skill+> <!ELEMENT skill EMPTY>
Fig 10. Part of a DTD
This DTD description says a large number of things in a compact way. The first thing that it states is that there are two sorts of tags involved in the resume file; tags called resume, and tags called skill.
The first ELEMENT description says that resume tags contain skill tags. The + sign stands for the idea of one or more. So you can read the first line of the DTD as:
resume tags contain one or more skill tags.
The second element description states that skill tags are empty tags. If we were using this DTD we could state that figs 6 and 7 fitted since every resume tag contains one or more skill tags but that the nonsense example in figure 8 did not fit the DTD since resume tags are not allowed to contain parish tags.
Here's a slight variation on the DTD:
<!ELEMENT resume skill*> <!ELEMENT skill EMPTY>
Fig 11. A slightly different DTD
In this DTD the '+' sign (which means one or more) has been replaced with a * sign. The * means zero or more. You can read this DTD as
resume tags contain zero or more skill tags and skill tags are empty.
If we use the DTD in figure 11, I can write the following properly structured XML file.
<?xml version = "1.0" ?> <resume name = "Mr. Politician" tel = "787744"> </resume>
Fig 12. Someone with no skills
This is a resume for someone with no skills. The DTD in figure 10 does not allow this because it states that resume tags must contain at least one skill tag, the DTD in figure 11 is slightly more general because it allows files to be written with no skills at all. If we were feeling particularly clever we could abbreviate figure 12 as:
<?xml version = "1.0" ?> <resume name = "Mr. Politician" tel = "787744"/>
Fig 13. Another way of writing this file.
We can use a DTD to state where text is allowed as well. The very first example of XML in this document was Figure 2 that contains street tags. The DTD for this would contain the following element description:
<!ELEMENT street #PCDATA>
Fig 14. Text in a DTD
This element description states that street tags contain Printable Character Data in other words, ordinary text.
There's one more symbol needed before we leave the subject of DTDs, and this is , the comma which is used to represent the idea of followed by.
Suppose we decide to include a contact address in our resume files. For example we might want the following kind of file to be acceptable:
<?xml version = "1.0" ?> <resume name = "Peter Jones" tel = "976765"> <address>25 High St. St Peter Port, Guernsey, GY1 1RG</address> <skill type = "Cooking"/> <skill type = "Driving"/> </resume>
Fig 15. A Resume with an address.
The existing DTD does not allow files of this kind. We have to change it in the following way.
<!ELEMENT resume (address, skill*)> <!ELEMENT address #PCDATA> <!ELEMENT skill EMPTY>
Fig 16. A DTD for resumes with addresses
This DTD does says that the resume tag contains an address tag followed by zero or more skill tags. The '(' and the ')' are there to group address and skill together with the ',' - which means followed by. The DTD goes on to say that an address tag contains some text (#PCDATA) and that the skill tags are empty. Because of the way this particular DTD is structured, all resumes would now have to contain an address tag so the existing documents would have to be adjusted.
DTDs are a complicated subject - not fully covered here. You can use them to specify what attributes are allowed or to permit optional parts of documents as well. However, you now have enough information about XML files and DTDs to understand simple Webflow scripting.