Learning XML Basics


Although the name XML, for Extensible Markup Language, sounds a bit cryptic, it is actually quite easy to understand. In a nutshell, XML provides a way of formatting and structuring information so that receiving applications can easily interpret and use that data when it's moved from place to place.

You may not realize it, but you already have plenty of experience in organizing information. Consider, for example, the following. If you wanted to write a letter to a friend, you would structure your thoughts (information) in a format you know your friend would recognize. Thus, you would begin by writing words on a piece of paper, starting probably somewhere near the upper-left corner, breaking your thoughts into paragraphs, sentences, and words. You could, of course, use images to convey your thoughts, or write your words in circular fashion, but that would most likely just confuse your friend. By writing your letter in a format your friend is accustomed to, you can be confident that your message will be conveyed that is, you will have transferred your thoughts (data/information) to the letter's recipient. When you want to write a different kind of letter say, a complaint to a neighbor for her dog's behavior on your newly seeded lawn you can use the same proven-successful format to get a very different message across.

graphics/dfig01.gif

You can use XML in much the same way as a format for conveying information. If, for instance, you wanted to send data out of Flash for processing by a Web server, you would first format that data in XML. The server would then interpret the XML-formatted data and use it in the manner intended. Without XML, you could send chunks of data to a server, but the server probably wouldn't know what to do with the first chunk, or the second, or even know how the first chunk related to the second. XML gives meaning to these disparate bits of data so that the server can work with them in an organized and intelligent manner.

XML's simple syntax resembles HTML in that it employs tags, attributes, and values but the similarity ends there. While HTML uses predefined tags (for example, body, head, and html), in XML you create your own; that is, you don't pull them from an existing library of tag names. Before going any further, let's take a look at this simple XML document:

 <MyFriends>     <Name Gender="female">Kelly Makar</Name>    <Name Gender="male">Mike Grundvig</Name>    <Name Gender="male">Free Makar</Name> </MyFriends> 

Each tag in XML is called a node, and any XML-formatted data is called an XML document. The above document has a root node called MyFriends and three child nodes. Each XML document can contain only one root node. The first child node has a node name of Name and a node value of Kelly Makar. The word Gender in each child node is an attribute. Attributes are optional, and each node can have an unlimited number of attributes. You will typically use attributes to store small bits of information that are not necessarily displayed on the screen (for example, a user identification number).

graphics/dfig02.gif

As you can see in this example, the tags (which we made up and defined) give meaning to the bits of information shown (Kelly Makar, Mike Grundvig, and Free Makar). This is why XML is so useful.

This next XML document shows a more extended use of XML:

 <AddressBook>     <Person>       <Name>Kelly Makar</Name>       <Street>121 Baker Street</Street>       <City>Some City</City>       <State>North Carolina</State>    </Person>    <Person>        <Name>Tripp Carter</Name>        <Street>777 Another Street</Street>        <City>Elizabeth City</City>        <State>North Carolina</State>    </Person> </AddressBook> 

This example shows how the data in an address book would be formatted in XML. If there were 600 people in the address book, the Person node would appear 600 times with the same structure.

So how do you actually create your own nodes and structure? How does the destination (Active Server Page [ASP], socket, and so on) know how the document is formatted? And how does it know what to do with each piece of information? The simple answer is that the destination by nature has no idea what to do with this information you are sending you (or someone else) must also program the destination script or socket server to understand the data. Thus, if we were to build an address book in Flash and wanted the information it contained to be saved in a database, we would send an XML-formatted version of that data to an ASP (or another scripted page of choice), which would then parse that information and insert it into the appropriate fields in a database. The important thing to remember is that the ASP must be designed to deal with data in this way. Since XML is typically used to transfer rather than store information, the address-book data would be stored as disparate information in database fields rather than as XML. When needed again, that information could be extracted from the database, formatted to XML by a scripted page, and sent along to Flash or any other application that requested it.

graphics/dfig03.gif

That said, you may sometimes use text files that contain XML-formatted information for example, a static XML file for storing information about which ASPs should be called, or what port and IP to connect to when attempting to connect with a socket server.

To briefly recap, XML can be

  • Sent to a server-side script

  • Sent to a socket server

  • Stored in a text file (that you can load into Flash anytime)

  • Stored in a database and retrieved by requesting it from a server-side script

Now that you know the basics of the XML structure, here are some rules you need to follow when you begin using it.

  • Don't begin node names with the letters XML; many XML parsers will break when they see this. For instance, <myXML> is OK, but <XMLdoc> is not.

  • Properly terminate every node for example, you would terminate <Name> with </Name>.

  • Use the escape() function in Flash to URL-encode all odd characters. Many parsers will interpret certain unencoded characters as the start of a new node that is then not terminated properly (since it wasn't a node in the first place). An XML document with non-terminated nodes will not pass through an XML parser completely. Attributes are less forgiving than text nodes because they can fail to pass through the parser on more characters, such as a carriage return or an ampersand. If you URL-encode the text, you will not experience any trouble with this.

  • Keep the text case consistent. Most XML parsers are case-sensitive, which means that all tags of the same type must have the same case. In other words, if you start a node with <Name> and terminate it with </name>, you're asking for trouble!

  • You can have only one root node.

graphics/tip_icon.gif

One more thing to note before you begin working with XML is that the clean XML structure shown in the address-book example above is not necessary. The carriage returns and tabs are there to make it easier for us to read. These tabs and carriage returns are called white space, and you can add or delete them without affecting the overall structure.



Macromedia Flash MX Game Design Demystified(c) The Official Guide to Creating Games with Flash
Macromedia Flash MX Game Design Demystified: The Official Guide to Creating Games with Flash -- First 1st Printing -- CD Included
ISBN: B003HP4RW2
EAN: N/A
Year: 2005
Pages: 163
Authors: Jobe Makar

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net