Martha's COIN 74 Week 8

Martha's COIN 74 Week 8 Exercises

Day Three - More XML

SOURCE: Robert D. Cormia's online text
my comments in blue

Martha's Family Nested XML
Martha's Family Empty XML
Martha's Family Mixed XML
nesting error (check source code to find error)

MORE ON XML

Attribute Like HTML, the elements of an XML document can support attributes. Attributes extend an element's capacity of structuring a document by packing additional information about that element.
Entity References An Entity is an instruction that the XML parser would substitutes after parsing the document. Entities are not new at all. The page you are viewing is using the entity "<" to display the "<". This is because the HTML tag, and XML tags as well, are indicated by being encompassed within "< >" characters. Therefore, in this case it would be impossible to display them on the screen without the parser first parsing them. The XML language has 5 built in entity references (< <), (> >), (& &), (' '), and (" "). These entity references are derived from SGML, hence their appearance in HTML.
CDATA? PCDATA? So what type of stuff can be placed within an element? Here we come across this CDATA PCDATA stuff. For starters, any text placed within the elements are by default of type Parsed Character DATA (PCDATA). This means the data will be parsed by the XML parser. In contrast to PCDATA would be the plain old Character DATA (CDATA), data that is not parsed by the parser. As you can remember in our Entity example we had to use the < characters to encode the text HTML to make the parser replace it with <. But, CDATA (data) does not get parsed so there is no reason to use any entities. If you are very detailed you should also notice that there is some white space within the HTML and BODY in the choice "c". The white space in CDATA is preserved since the parser never parses this data and therefore the white space is not converted to a single white space as it would normally would.

PUTTING XML TOGETHER

Empty Elements If you have had any HTML experience (of course you do) you have seen cases in which an opening tag and a closing tag is not really needed. One of the best cases is the image tag, <IMG src="some url" >. The paragraph tag <P>, bold <B>, break <BR> are other examples. Since, XML requires every element to have an ending element, a special syntax was devised to handle, "empty tags". The syntax of an empty tag would be, "<IMG src="some url" />" , <br />. When I send email, I often use <snip> to divide sections for meaning. Technically I should use <snip />. Sorry, oops, <sorry />. Here's an address book snippet with empty elements.
To Nest or Not to Nest One of the main questions that everyone has to go through as they design an XML document is to use nesting or to use an attribute. If you need the hierarchical data structure you should nest (non-empty elements) otherwise attributes are a bit more efficient to parse. Some types of information lend themselves better if they are organized in a hierarchical order rather than sequential. However, the W3C has said the performance should not be a criteria in design of XML. Nesting adds organization, but be wary of over nesting (too many levels). In general, most 'ontologies' will have three levels, so for an XML data structure, a data model with three levels is (usually) just fine.
Mixed elements - Think of empty and nested as hot and cold water. Most of us use 'warm' water, which we produce by mixing some hot and some cold. Plumbing only comes in hot and cold, so that's where we start. The *majority* of human designed XML code is in a nested format, and the *majority* of machine generated code is empty. The code I use (in biological applications) is mostly empty with some nested, and a fair amount of 'mixed' character. Take a close look at the six example files below, they will help you understand each style. An address book with mixed elements is shown here.
Ordinal counting - now this is where it gets a little tricky. Before you read any further, make sure that you have looked at the mixed files (above). Some data models have an element of 'counting' to them. For instance, in a recipe, you might have ingredients and steps. What you want to avoid doing is having numbers or any notion of counting in an element. Elements like <ingredient_1>, <ingedient_2>, <ingedient_3>, and <step_1>, <step_2>, and <step_3> are such an example. If you find yourself 'counting' in your element names, in either the nested or the empty model, you probably should be using attributes, or 'mixed' character in your nested and empty models. Take a look at recipe_counting.xml . That's the *wrong* way to do it. Now take a look at recipe_attributes.xml - that's the *right* way to do it. If you have a model where there is a any notion of order or sequence, try designing after these files: recipe_attributes_nested.xml and recipe_attributes_empty.xml. For advanced students, I have created an assertion network of attributes.

XML EXAMPLES

Students may also want to look at address_book_mixed.xml and download the entire Address_Book.zip archive.