Ivor Horton’s Beginning Java 2, JDK 5 Edition phần 9 pot

An important aspect of defining possible attribute values by an enumeration like this is that an XML edi- tor can help the author of a document by prompting with the list of possible attribute values from the DTD when the element is being created. An attribute that you declare as #FIXED must always have the default value. For example: <!ATTLIST circle color (red|blue|green) #REQUIRED line_thickness medium #FIXED > Here the XML processor will supply an application only with the value medium for the thickness attribute. If you were to specify this attribute for the <circle> element in the body of the document you can use only the default value; otherwise, it is an error. Defining Parameter Entities You will often need to repeat a block of information in different places in a DTD. A parameter entity identifies a block of parsed text by a name that you can use to insert the text at various places within a DTD. Note that parameter entities are for use only within a DTD. You cannot use parameter entity refer- ences in the body of a document. You declare general entities in the DTD when you want to repeat text within the document body. The form for a parameter entity is very similar to what you saw for general entities except that a % char- acter appears between ENTITY and the entity name, separated from both by a space. For example, it is quite likely that you would want to repeat the x and y attributes that you defined in the <position> element in the previous section in other elements. You could define a parameter entity for these attributes and then use that wherever these attributes should appear in an element declaration. Here’s the parameter entity declaration: <!ENTITY % coordinates “x CDATA #REQUIRED y CDATA #REQUIRED”> Now you can use the entity name to insert the x and y attribute definitions in an attribute declaration: <!ATTLIST position %coordinates; > A parameter entity declaration must precede its use in a DTD. The substitution string in a parameter entity declaration is parsed and can include parameter and gen- eral entity references. As with general entities, a parameter entity can also be defined by a reference to a URI containing the substitution string. Other Types of Attribute Value There are a further eight possibilities for specifying the type of the attribute value. I won’t go into detail on these, but so you can recognize them, they are as follows: 1171 Java and XML 25_568744 ch22.qxd 11/23/04 9:38 PM Page 1171 ENTITY An entity defined in the DTD. An entity here is a name identifying an unparsed entity defined elsewhere in the DTD by an ENTITY tag. The entity may or may not contain text. An entity could represent something very simple such as &lt;, which refers to a single character, or it could represent something more substan- tial such as an image. ENTITIES A list of entities defined in the DTD, separated by spaces. ID An ID is a unique name identifying an element in a document. This is to enable internal references to a particular element from elsewhere in the document. IDREF A reference to an element elsewhere in a document via its ID. IDREFS A list of references to IDs, separated by spaces. NMTOKEN A name conforming to the XML definition of a name. This just says that the value of the attribute will be consistent with the XML rules for a name. NMTOKENS A list of name tokens, separated by spaces. NOTATION A name identifying a notation— which is typically a format specification for an entity such as 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 you know of XML and DTDs, you can have a stab at putting together a DTD for storing Sketcher files as XML. As I 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, the objective here is to exercise your knowledge of XML and DTDs, so you’ll reinvent your own version of this wheel, even though it will have fewer spokes and may wob- ble a bit. First, let’s consider what the general approach is going to be. Since the objective is to define a DTD that will enable you to exercise the Java API for XML with Sketcher, you’ll 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 ele- ment. 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, you’ll just map these directly in XML to avoid the mathematical jiggery- pokery that would be necessary if you 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. You 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. You now need to define each of these elements. 1172 Chapter 22 25_568744 ch22.qxd 11/23/04 9:38 PM Page 1172 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. You 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 the Line class includes a rotation field, so you 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. You 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 you can define the <color> element as: <!ELEMENT color EMPTY> <!ATTLIST color R CDATA #REQUIRED G CDATA #REQUIRED B CDATA #REQUIRED > You must now define the <position> and <endpoint> elements. These are both points defined by an (x, y) coordinate pair, so you would sensibly define them consistently. Empty elements with attributes are the most economical way here, and you can use a parameter entity for the attributes: <!ENTITY % coordinates “x CDATA #REQUIRED y CDATA #REQUIRED”> <!ELEMENT position EMPTY> <!ATTLIST position %coordinates;> <!ELEMENT endpoint EMPTY> <!ATTLIST endpoint %coordinates;> A rectangle will be defined very similarly to a line since it is defined by its position, which corresponds to the top-left corner, plus the coordinates of the bottom-right corner. It also has a color and a rotation angle. Here’s how this will look in the DTD: <!ELEMENT rectangle (color, position, bottomright)> <!ATTLIST rectangle angle CDATA #REQUIRED > <!ELEMENT bottomright EMPTY> <!ATTLIST bottomright %coordinates;> You don’t need to define the <color> and <position> elements because you have already defined these earlier for the <line> element. The <circle> element is no more difficult. Its position is the center, and it has a radius and a color. It also has a rotation angle. You can define it like this: 1173 Java and XML 25_568744 ch22.qxd 11/23/04 9:38 PM Page 1173 <!ELEMENT circle (color, position)> <!ATTLIST circle radius CDATA #REQUIRED angle CDATA #REQUIRED > The <curve> element is a little more complicated because it’s defined by an arbitrary number of points, but it’s still quite easy: <!ELEMENT curve (color, position, point+)> <!ATTLIST curve angle CDATA #REQUIRED> <!ELEMENT point EMPTY> <!ATTLIST point %coordinates;> The start point of the curve is defined by the <position> element, and it includes at least one <point> element, which is specified by the + operator. Lastly, you have the element that defines a text element in Sketcher terms. You need to allow for the font name and its style and point size, a rotation angle for the text, and a color— plus the text itself, of course, and its position. A Text element is also a little different from the other elements, as its bounding rectangle is required to construct it, so you must also include that. You have some options as to how you define this element. You could use mixed element content in a <text> element, combining the text string with <font> and <position> elements, for example. The disadvantage of this is that you cannot limit the number of occurrences of the child elements and how they are intermixed with the text. You can make the definition more precisely controlled by enclos- ing the text in its own element. Then you can define the <text> element as having element content — like this: <!ELEMENT text (color, position, font, string)> <!ATTLIST text angle CDATA #REQUIRED> <!ELEMENT font EMPTY> <!ATTLIST font fontname CDATA #REQUIRED fontstyle (plain|bold|italic) #REQUIRED pointsize CDATA #REQUIRED > <!ELEMENT string (#PCDATA|bounds)*> <!ELEMENT bounds EMPTY> <!ATTLIST point width CDATA #REQUIRED height CDATA #REQUIRED > The <string> element content will be a <bounds> element defining the height and width of the bound- ing rectangle plus the text to be displayed. The <font> element provides the name, style, and size of the font as attribute values, and since nothing is required, beyond that it is an empty element. Children of the <text> element that you have already defined specify the color and position of the text. 1174 Chapter 22 25_568744 ch22.qxd 11/23/04 9:38 PM Page 1174 That’s all you need. The complete DTD for Sketcher documents will be: <?xml version=”1.0” encoding=”UTF-8”?> <!ELEMENT sketch (line|circle|rectangle|curve|text)*> <!ELEMENT color EMPTY> <!ATTLIST color R CDATA #REQUIRED G CDATA #REQUIRED B CDATA #REQUIRED > <!ENTITY % coordinates “x CDATA #REQUIRED y CDATA #REQUIRED”> <!ELEMENT position EMPTY> <!ATTLIST position %coordinates;> <!ELEMENT endpoint EMPTY> <!ATTLIST endpoint %coordinates;> <!ELEMENT line (color, position, endpoint)> <!ATTLIST line angle CDATA #REQUIRED > <!ELEMENT rectangle (color, position, bottomright)> <!ATTLIST rectangle angle CDATA #REQUIRED > <!ELEMENT bottomright EMPTY> <!ATTLIST bottomright %coordinates;> <!ELEMENT circle (color, position)> <!ATTLIST circle radius CDATA #REQUIRED angle CDATA #REQUIRED > <!ELEMENT curve (color, position, point+)> <!ATTLIST curve angle CDATA #REQUIRED> <!ELEMENT point EMPTY> <!ATTLIST point %coordinates;> <!ELEMENT text (color, position, font, string)> <!ATTLIST text angle CDATA #REQUIRED> <!ELEMENT font EMPTY> <!ATTLIST font fontname CDATA #REQUIRED fontstyle (plain|bold|italic|bold-italic) #REQUIRED pointsize CDATA #REQUIRED > 1175 Java and XML 25_568744 ch22.qxd 11/23/04 9:38 PM Page 1175 <!ELEMENT string (#PCDATA|bounds)*> <!ELEMENT bounds EMPTY> <!ATTLIST bounds width CDATA #REQUIRED height CDATA #REQUIRED > You can use this DTD to represent any sketch in XML. Stash it away in your Beg Java Stuff directory as sketcher.dtd. You’ll try it out later. Rules for a Well-Formed Document Now that you know a bit more about XML elements and what goes into a DTD, I can formulate what you must do to ensure your XML document is well-formed. The rules for a document to be well-formed are quite simple: 1. If the XML declaration appears in the prolog, it must include the XML version. Other specifica- tions in the XML document must be in the prescribed sequence— character encoding followed by standalone specification. 2. If the document type declaration appears in the prolog, the DOCTYPE name must match that of the root element, and the markup declarations in the DTD must be according to the rules for writing markup declarations. 3. The body of the document must contain at least one element, the root element, which contains all the other elements, and an instance of the root element must not appear in the content of another element. All elements must be properly nested. 4. Elements in the body of the document must be consistent with the markup declarations identi- fied by the DOCTYPE declaration. The rules for writing an XML document are absolutely strict. Break one rule and your document is not well-formed and will not be processed. This strict application of the rules is essential because you are communicating data and its structure. If any laxity were permitted, it would open the door to uncer- tainty about how the data should be interpreted. HTML used to be quite different from XML in this respect. Until recently, the rules for writing HTML were only loosely applied by HTML readers such as web browsers. For example, even though a paragraph in HTML should be defined using a start tag, <p>, and an end tag, </p>, you can usually get away with omitting the end tag, and you can use both capital and lower- case p, and indeed close a capital P paragraph with a lowercase p, and vice versa. You can often have overlapping tags in HTML and get away with that, too. While it is not to be recommended, a loose appli- cation of the rules for HTML is not so harmful since HTML is concerned only with data presentation. The worst that can happen is that the data does not display quite as you intended. 1176 Chapter 22 25_568744 ch22.qxd 11/23/04 9:38 PM Page 1176 In 2000, the W3C released the XHTML 1.0 standard that makes HTML an XML language, so you can expect more and more HTML documents to conform to this. The enduring problem is, of course, that the Internet has accumulated a great deal of material over many years that is still very useful but that will never be well-formed XML, so browsers may never be fully XML-compliant. XML Namespaces Even though they are very simple, XML namespaces can be very confusing. The confusion arises because it is so easy to make assumptions about what they imply when you first meet them. Let’s look briefly at why you have XML namespaces in the first place, and then see what an XML namespace actually is. You saw earlier that an XML document can have only one DOCTYPE declaration. This can identify an external DTD by a URI or include explicit markup declarations, or it may do both. What happens if you want to combine two or more XML documents that each has its own DTD into a single document? The short answer is that you can’t — not easily anyway. Since the DTD for each document will have been defined without regard for the other, element name collisions are a real possibility. It may be impossible to differentiate between different elements that share a common name, and in this case major revisions of the documents’ contents as well as a new DTD will be necessary to deal with this. It won’t be easy. XML namespaces are intended to help deal with this problem. They enable names used in markup to be qualified so that you can make duplicate names that are used in different markup unique by putting them in separate namespaces. An XML namespace is just a collection of element and attribute names that is identified by a URI. Each name in an XML namespace is qualified by the URI that identifies the namespace. Thus, different XML namespaces may contain common names without causing confusion since each name is notionally qualified by the unique URI for the namespace that contains it. I say “notionally qualified” because you don’t usually qualify names using the URI directly, although you could. Normally, in the interests of not making the markup overly verbose, you use another name called a namespace prefix whose value is the URI for the namespace. For example, I could have a namespace that is identified by the URI http://www.wrox.com/Toys and a namespace prefix toys that contains a declaration for the name rubber_duck. I could have a second namespace with the URI http://www.wrox.com/BathAccessories and the namespace prefix bathAccessories that also defines the name rubber_duck. The rubber_duck name from the first namespace is referred to as toys:rubber_duck and that from the second namespace is bathAccessories:rubber_duck, so there is no possibility of confusing them. The colon is used in the qualified name to separate the namespace prefix from the local name, which is why I said earlier in the chapter that you should avoid the use of colons in ordinary XML names. Let’s come back to the confusing aspects of namespaces for a moment. There is a temptation to imagine that the URI that identifies an XML namespace also identifies a document somewhere that specifies the names in the namespace. This is not required by the namespace specification. The URI is just a unique identifier for the namespace and a unique qualifier for a set of names. It does not necessarily have any other purpose, or even have to refer to a real document; it only needs to be unique. The definition of how names within a given namespace relate to one another and the rules for markup that uses them is an entirely separate question. This may be provided by a DTD or some other mechanism such as an XML Schema. 1177 Java and XML 25_568744 ch22.qxd 11/23/04 9:38 PM Page 1177 Namespace Declarations A namespace is associated with a particular element in a document, which of course can be, but does not have to be, the root element. A typical namespace declaration in an XML document looks like this: <sketcher:sketch xmlns:sketcher=”http://www.wrox.com/dtds/sketches”> A namespace declaration uses a special reserved attribute name, xmlns, within an element, and in this instance the namespace applies to the <sketch> element. The name sketcher that is separated from xmlns by a colon is the namespace prefix, and it has the value http://www.wrox.com/dtds/sketches. You can use the namespace prefix to qualify names within the namespace, and since this maps to the URI, the URI is effectively the qualifier for the name. The URL that I’ve given here is hypothetical— it doesn’t actually exist, but it could. The sole purpose of the URI identifying the namespace is to ensure that names within the namespace are unique, so it doesn’t matter whether it exists or not. You can add as many namespace declarations within an element as you want, and each namespace declared in an element is available within that element and its content. With the namespace declared with the sketcher prefix, you can use the <circle> element that is defined in the sketcher namespace like this: <sketcher:sketch xmlns:sketcher=”http://www.wrox.com/dtds/sketches”> <sketcher:circle radius=”15” angle=”0”> <sketcher:color R=”150” G=”250” B=”100”/> <sketcher:position x=”30” y=”50”/> </sketcher:circle> </sketcher:sketch> Each reference to the element name is qualified by the namespace prefix sketcher. A reference in the same document to a <circle> element that is defined within another namespace can be qualified by the prefix specified in the declaration for that namespace. By qualifying each element name by its names- pace prefix, you avoid any possibility of ambiguity. A namespace has scope— a region of an XML document over which the namespace declaration is visi- ble. The scope of a namespace is the content of the element within which it is declared, plus all direct or indirect child elements. The preceding namespace declaration applies to the <sketch> element and all the elements within it. If you declare a namespace in the root element for a document, its scope is the entire document. You can declare a namespace without specifying a prefix. This namespace then becomes the default namespace in effect for this element, and its content and unqualified element names are assumed to belong to this namespace. Here’s an example: <sketch xmlns=”http://www.wrox.com/dtds/sketches”> There is no namespace prefix specified so the colon following xmlns is omitted. This namespace becomes the default, so you can use element and attribute names from this namespace without qualifica- tion and they are all implicitly within the default namespace. For example: 1178 Chapter 22 25_568744 ch22.qxd 11/23/04 9:38 PM Page 1178 <sketch xmlns=”http://www.wrox.com/dtds/sketches”> <circle radius=”15” angle=”0”> <color R=”150” G=”250” B=”100”/> <position x=”30” y=”50”/> </circle> </sketch> This markup is a lot less cluttered than the earlier version that used qualified names, which makes it much easier to read. It is therefore advantageous to declare the namespace that you use most extensively in a document as the default. You can declare several namespaces within a single element. Here’s an example of a default namespace in use with another namespace: <sketch xmlns=”http://www.wrox.com/dtds/sketches” xmlns:print=”http://www.wrox.com/dtds/printed”> <circle radius=”15” angle=”0”> <color R=”150” G=”250” B=”100”/> <position x=”30” y=”50”/> </circle> <print:circle print:lineweight=”3” print:linestyle=”dashed”/> </sketch> Here the namespace with the prefix print contains names for elements relating to hardcopy presenta- tion of sketch elements. The <circle> element in the print namespace is qualified by the namespace prefix so it is distinguished from the element with the same name in the default namespace. XML Namespaces and DTDs For a document to be valid, you must still have a DTD, and the document must be consistent with it. The way in which a DTD is defined has no specific provision for namespaces. The DTD for a document that uses namespaces must therefore define the elements and attributes using qualified names and must also make provision for the xmlns attribute with or without its prefix in the markup declaration for any ele- ment in which it can appear. Because the markup declarations in a DTD have no specific provision for accommodating namespaces, a DTD is a less than ideal vehicle for defining the rules for markup when namespaces are used. The XML Schema specification provides a much better solution, and overcomes a number of other problems associated with DTDs. XML Schemas Because of the limitations of DTDs that I mentioned earlier, the W3C has developed the XML Schema language for defining the content and structure of sets of XML documents, and this language is now a W3C standard. You use the XML Schema Definition language to create descriptions of particular kinds of XML documents in a similar manner to the way you use DTDs, and such descriptions are themselves referred to as XML Schemas and fulfill the same role as DTDs. The XML Schema language is itself defined in XML and is therefore implicitly extensible to support new capabilities when necessary. Because the XML Schema language enables you to specify the type and format of data within an XML document, it provides a way for you to define and create XML documents that are inherently more pre- cise, and therefore safer than documents described by a DTD. 1179 Java and XML 25_568744 ch22.qxd 11/23/04 9:38 PM Page 1179 It’s easy to get confused when you are working with XML Schemas. One primary source of confusion is the various levels of language definition you are involved with. At the top level, you have XML— every- thing you are working with in this context is defined in XML. At the next level you have the XML Schema Definition language — defined in XML of course— and you use this language to define an XML Schema, which is a specification for a set of XML documents. At the lowest level you define an XML doc- ument — such as a document describing a Sketcher sketch— and this document is defined according to the rules you have defined in your XML Schema for Sketcher documents. Figure 22-3 shows the relation- ships between these various XML documents. Figure 22-3 The XML Schema language is sometimes referred to as XSD, from XML Schema Definition language. The XML Schema namespace is usually associated with the prefix name xsd, and files containing a defi- nition for a class of XML documents often have the extension .xsd. You’ll also often see the prefix xs used for the XML Schema namespace, but in fact you can use anything you like. A detailed discussion of the XML Schema language is a substantial topic that really requires a whole book to do it justice, so I’ll just give you enough of a flavor of how you define your own XML documents schemas so that you’re able to how it differs from a DTD. XML Schema for Sketcher Documents XML Sketch XML Sketch All these documents are defined in XML. XML Sketch XML Schema Definition Language XML was used to define a language in which you can define XML Schema. You define an XML Schema for XML documents that define Sketcher sketches. Sketcher sketches can be stored and retrieved or otherwise communicated as long as they conform to the XML Schema. XML 1180 Chapter 22 25_568744 ch22.qxd 11/23/04 9:38 PM Page 1180 [...]... definition Here are a few other examples: Data Type Examples of Data integer 25, -99 8, 123 45, 0, -1 negativeInteger -1, -2, -3, -123 45, and so on nonNegativeInteger 0, 1, 2, 3, and so on hexBinary 0DE7, ADD7 long 25, 123 456 7 89, -99 999 99 float 2.71828, 5E5, 50 0.0, 0, -3E2, -300.0, NaN, INF, -INF double 3.14 152 65, 1E30, -2 .5, NaN, -INF, INF boolean true, false, 1, 0 date 2004-12-31 language en-US, en,... type Document that encapsulates it, as Figure 22 -5 illustrates XML 15 30 50 Returned to your Program circle radius position 15 x-coordinate y-coordinate 30 50 Document Object DOM Processing of XML Figure 22 -5 11 95 Chapter 22 Once you have the Document object... parser and the parser does the job of figuring out what the document consists of Java supports two complementary APIs for processing an XML document: ❑ SAX, which is the Simple API for XML parsing ❑ DOM, which is the Document Object Model for XML The support in JDK 5. 0 is for DOM level 3 and for SAX version 2.0.2 JDK 5. 0 also supports XSLT version 1.0, where XSL is the Extensible Stylesheet Language... definition of an interface to an XML parser, where the parser is an external program The public domain part of the SAX API is in three packages that are shipped as part of the JDK: 1 194 Java and XML ❑ org.xml.sax — This defines the Java interfaces specifying the SAX API and the InputSource class that encapsulates a source of an XML document to be parsed ❑ org.xml.sax.helpers — This defines a number of... or to obtain information about comments and CDATA sections in a document In addition to these, the javax.xml.parsers package provides factory classes that you use to gain access to a parser, and the javax.xml.transform package defines interfaces and classes for XSLT 1.0 processing of an XML document In Java terms there are several interfaces involved The XMLReader interface defined in the org.xml.sax... version="1.0"> 15 30 50 Start document Start element Start element Characters End element Start element Start element Characters End element Start element Characters End element End element End element End document : : : : : : : : : : : : : : : circle radius 15 radius position x-coordinate... to allow different parsers and their factory classes to be plugged in Both DOM and SAX parsers are developed independently of the Java JDK so it is important to be able to integrate new parsers as they come along The Xerces parser that is currently distributed with the JDK is controlled and developed by the Apache Project, and it provides a very comprehensive range of capabilities However, you may... with the parser that you want to use The first step toward this is to create a SAXParserFactory object like this: SAXParserFactory spf = SAXParserFactory.newInstance(); 1 196 Java and XML The SAXParserFactory class is defined in the javax.xml.parsers package along with the SAXParser class that encapsulates a parser The SAXParserFactory class is abstract but the static newInstance() method will return... not have the capability for validating documents, this exception would be thrown This should not arise with the parser supplied with the JDK though, because it supports both of these features 1 197 Chapter 22 The ParserConfigurationException class is defined in the javax.xml.parsers package and the SAXException class is in the org.xml.sax package Now let’s see what the default parser is by putting the... in a working example Try It Out Accessing a SAX Parser Here’s the code to create a SAXParser object and output some details about it to the command line: import javax.xml.parsers.SAXParserFactory; import javax.xml.parsers.SAXParser; import javax.xml.parsers.ParserConfigurationException; import org.xml.sax.SAXException; public class TrySAX { public static void main(String args[]) { // Create factory . Data integer 25, -99 8, 123 45, 0, -1 negativeInteger -1, -2, -3, -123 45, and so on nonNegativeInteger 0, 1, 2, 3, and so on hexBinary 0DE7, ADD7 long 25, 123 456 7 89, -99 999 99 float 2.71828, 5E5, 50 0.0,. example: 1178 Chapter 22 25_ 568744 ch22.qxd 11/23/04 9: 38 PM Page 1178 <sketch xmlns=”http://www.wrox.com/dtds/sketches”> <circle radius=” 15 angle=”0”> <color R=” 150 ” G=” 250 ” B=”100”/> <position. pre- cise, and therefore safer than documents described by a DTD. 11 79 Java and XML 25_ 568744 ch22.qxd 11/23/04 9: 38 PM Page 11 79 It’s easy to get confused when you are working with XML Schemas.