next up previous
Next: Using the provided XML Up: Part 1: PR Quadtrees Previous: Drawing a spatial map

A command interpreter for XML

If you haven't heard of XML yet, now is a good time to read up. XML stands for extensible markup language and is a standard for textual data representation. If you haven't used XML yet at work or for another class, you will probably see it soon. XML is a tag-based hierarchical organization of data (i.e., a data structure). If you want to look at an XML document through a data structures lens, an XML document is a general tree whose nodes are either named tags or blocks of text. A great site with great tutorials that cover the basics of XML is available at www.w3schools.com.

Google will also tell you everything you want to know about XML--it's so widespread at this point that there are probably hundreds of tutorials already written-and this document, like my exams, is already too long.

For your project, your input and output will be in XML format. XML is convenient because it is designed to be validated (in other words, checked for correctness). Every XML document can optionally include a reference to its W3C XML Schema (commonly referred to just as XML Schema) which is an external XML document that contains the rules for what elements an XML document can contain. In other words, a schema defines the rules for the XML structure. Thus, by validating an XML document against a schema, you can quickly determine whether or not the XML contains certain kinds of errors. If you happen to have handy a solid XML parser and a solid schema validator, you can eliminate the majority of possible input/output errors. Fortunately for you, they are included in the Java 7.0 API and the files we provide do a lot of the work for you.

At this point I am going to assume you are familiar with XML. In order to test your project, you are going to provide a Java program (i.e., a class with a main() method) that will read a series of XML commands from an input stream, process those commands, and generate an XML document containing the results. For simplicity's sake, the input XML will be simple enough to process without using any XML tools and will in fact differ little from the command structure used in semesters past. The XML will simply be a sequence of empty elements whose names indicate the command to issue and whose attributes will provide the extra information, for example:

<createCity name=``A'' x=``5'' y=``25'' color=``red'' radius=``10''/>
<createCity name=``B'' x=``10'' y=``10'' color=``blue'' radius=``10'' />
...
<deleteCity name=``A'' />

and so forth. If you wanted, you could write your own command parser that treats these tags as merely strings with which you can do as you please, as students were required to do in previous semesters. However, because this is XML, it follows all of XML's rules and is free to do whatever it wants when there isn't an XML rule about it. For example, in XML attributes are not required to appear in any order. So for us, the following two commands are identical:

<createCity name=``X'' x=``0'' y=``0'' color=``yellow'' />
<createCity x=``0'' name=``X'' color=``yellow'' y=``0'' />
This will complicate your parsing slightly.

A few things to keep in mind--first, XML is case-sensitive when it comes to element and attribute names, so ``createCity'' is not the same as ``cReAtEcity''. Another thing to observe is that XML schemas can do type-checking for attributes and elements. So we can, for example, automatically enforce the restriction that the x and y attributes for the createCity command must adhere to the regular expression `(0|(-?[-9][0-9]*))' (more specifically, we can simply define them to be of integer type). So you do not have to refer to the spec for the regular expressions associated with certain attributes. Note-this makes your project code simpler, because much validation of data occurs at the world/program interface level. Some attributes, like color, have only a few legal values. Attributes whose values can be enumerated in a list of legal values can also be enforced by a schema, so you won't have to worry about those. In general:

Again, these type issues are all taken care of by the XML schema; so, as long as you have your validator configured properly you should be able to catch the exceptions thrown by your validator and do what you need to from there.



Subsections
next up previous
Next: Using the provided XML Up: Part 1: PR Quadtrees Previous: Drawing a spatial map
MM Hugue 2019-05-28