Java Reference
In-Depth Information
NOTATION
A name identifying a notation - which is typically a format specification for an
entity such a JPEG or Postscript file. The notation will be identified elsewhere in
the DTD using a NOTATION tag that may also identify an application capable of
processing an entity in the given format.
A DTD for Sketcher
With what we know of XML and DTDs, we can have a stab at putting together a DTD for storing Sketcher
files as XML. As we said before, an XML language has already been defined for representing and
communicating two-dimensional graphics. This is called Scalable Vector Graphics, and you can find it at
http://www.w3.org/TR/SVG/ . While this would be the choice for transferring 2D graphics as XML documents
in a real-world context, our objective is to exercise our knowledge of XML and DTDs, so we will reinvent
our own version of this wheel even though it will have fewer spokes and may wobble a bit.
First, let's consider what our general approach is going to be. Since our objective is to define a DTD that
will enable us to exercise the Java API for XML with Sketcher, we will define the language to make it an
easy fit to Sketcher, rather than worry about the niceties of the best way to represent each geometric
element. Since Sketcher itself was a vehicle for trying out various capabilities of the Java class libraries,
it evolved in a somewhat topsy-like fashion with the result that the classes defining geometric entities
are not necessarily ideal. However, we will just map these directly in XML in order to avoid the
mathematical jiggery-pokery that would be necessary if we adopted a more formal representation of
geometry in XML.
A sketch is a very simple document. It's basically a sequence of lines, circles, rectangles, curves, and
text. We can therefore define the root element, <sketch> , in the DTD as:
<!ELEMENT sketch (line|circle|rectangle|curve|text)*>
This just says that a sketch consists of zero or more of any of the elements between the parentheses. We
now need to define each of these elements.
A line is easy. It is defined by its location, which is its start point, and an end point. It also has an
orientation - its rotation angle - and a color. We could define a <line> element like this:
<!ELEMENT line (color, position, endpoint)>
<!ATTLIST line
angle CDATA #REQUIRED
>
A line is fully defined by two points, but our Line class includes a rotation field so we have included
that too. Of course, a position is also a point so it would be possible to use a <point> element for this,
but differentiating the position for a geometric element will make it a bit easier for a human reader to
read an XML document containing a sketch.
We could define color by a color attribute to the <line> element with a set of alternative values, but
to allow the flexibility for lines of any color, it would be better to define a <color> element with three
attributes for RGB values. In this case we can define the <color> element as:
Search WWH ::




Custom Search