Oracle XSQL- P16 docx

After observing these rules, you have a well-formed document. This is all that you need to use your HTML as an XSLT stylesheet. To go ahead and make your document XHTML, it must validate against one of the XHTML DTDs that are listed in Table 12.3. This involves putting a DOCTYPEdeclaration at the top of your file. When you transition your XHTML to an XSLT stylesheet, you will need to remove the DOCTYPE declaration. Generally, you are going to want to use the Transitional DTD. You declare this by using the following at the top of your document: <!DOCTYPE html PUBLIC “-//W3C//DTD XHTML 1.0 Transitional//EN” “http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd”> If you use frames and you want your frameset page to be XHTML, you need to use the following DOCTYPE declaration: <!DOCTYPE html PUBLIC “-//W3C//DTD XHTML 1.0 Frameset//EN” “http://www.w3.org/TR/xhtml1/DTD/xhtml1-frameset.dtd”> If you wish to use the Strict DTD, this is the declaration that you want: <!DOCTYPE html PUBLIC “-//W3C//DTD XHTML 1.0 Strict//EN” “http://www.w3.org/TR/xhtml1/DTD/strict.dtd”> The key requirement that both the Transitional and Strict DTDs enforce is that a head section is required. Even if it is empty, you still have to have it. The strict DTD goes a bit further on a couple of points: It is much stricter about structure and doesn’t allow deprecated attributes. Table 12.3 XHTML DTDs DTD DESCRIPTION Transitional Probably your best bet. It is loose and allows you to create code that is largely compatible with older HTML standards. Strict This DTD enforces all of XHTML rules, especially pertaining to how documents must be structured. Its use could cause backward compatibility problems for older browsers. Frameset The frameset DTD is used on pages that describe framesets. 280 Chapter 12 When using the Strict DTD, you will probably run into the structural requirements when a child element of the body tag isn’t a block element. Only block elements can be direct children of the body element. The following are block elements: HEADING ELEMENTS <h1> <h2> <h3> <h4> <h5> <h6> LIST ELEMENTS <ul> <ol> <dl> BLOCKTEXT ELEMENTS <pre> <hr> <blockquote> <address> <div> <table> <fieldset> <ins> <del> <script> <noscript> The other implication of this is that text can’t dangle inside the body tag. It must be enclosed in something—usually a <p> element. The Strict DTD also forbids the use of deprecated attributes. This is more troubling, because you lose compatibility with older browsers because of this. The structural requirements lead to better HTML, but using the Strict DTD works against good, open site design because it takes away older features from you. Generally, the Transitional DTD is preferred. XSLT 281 A Simple XHTML Transformation This section defines precisely what XHTML is and how it relates to traditional HTML. The first step is to look at a typical legal HTML document that isn’t XML compliant. Then, you’ll make it XML compliant by transitioning it to XHTML. This section concludes with a review that spells out the key rules that define XHTML. To begin, please consider the following HTML document: <html> <body> <H1>Hello!</H1> <p> <IMG SRC=blah.gif ID=my_picture> <br> Hi! This is my home page. I want to tell you a few things. <p> <ul> <li>I like playing on the Internet <li>I just want to dance! <li>I wok in the would </UL That’s about all <br> I have for now. <BR> <p> Maybe I’ll have <br> more to say <Br> later. <bR> <Hr> <b><i>Later!</B></I> </boDY> </HTML> This HTML is quite ugly, but it will work in most all Web browsers. However, it doesn’t stand a chance of being a valid stylesheet and is a long way from being valid XHTML. Let’s examine the worst offense first: <b><i>Later!</B></I> The tags aren’t properly nested. As you learned in Chapter 3, “Hello, XSQL!”, the tags have to be properly nested for an XML document to be well formed. The first step is therefore to straighten that out. This yields the following: <b><i>Later!</B></I> However, you still aren’t out of the woods. XML, unlike HTML, is case sensitive. These tags aren’t a well-formed fragment, because the closing tags are capitalized, whereas the opening tags aren’t. This line needs to be fixed to be: <b><i>Later!</b></i> 282 Chapter 12 Our document has this case mismatch with almost all of the opening and closing tags. Going through and making the end tags match all of the start tags fixes most of this problem. However, the one set of tags that already match have their own problem: <H1>Hello!</H1> XHTML requires that all element names be in lower case. Thus, this needs to be changed to: <h1>Hello!</h1> Now, all of the start tags have matching end tags, and all of the tag names are lowercase. However, our document still isn’t well formed. Our document includes several common HTML tags—<img>, <p>, <hr>, <br>, and <li>—that are illegal in XML. They have the form of the start tag, but they don’t have a matching end tag. They should either have an end tag or take the form of an empty tag. XHTML requires that the <img>, <hr>, and <br> tags should be empty tags, while <p> and <li> should be closed with </p> and </li>, respectively. These aren’t the only tags in traditional HTML that aren’t XML compliant. Table 12.1 describes how to handle the remaining tags that either should be empty or should be closed. But before exploring that, you are only a couple steps away from having an XHTML document. Our next problem deals with attributes. Attributes must be quoted, and the attribute names must be lowercase. This yields the following: <img src=”blah.gif” name=”my_picture” /> You need one other fix on the img element: The name attribute used by a, applet, frame, iframe, img, and map is deprecated in XHTML and replaced by the id attribute. The easiest way to fix this and to maintain compatibility is to specify the id attribute and the name attribute. Also, the alt attribute is required in XHTML. <img src=”blah.gif” name=”my_picture” id=”my_picture” alt=”blah blah blah”/> There is one fix left. The hr tag has a minimized attribute, “no_shade”. Such attributes aren’t allowed in XML, because attributes must have a value. The <hr> tag should be changed to: <hr noshade=”noshade”/> Now you have completed the transformation of the document to XHTML. Here is the final product. It validates against the Transitional XHTML DTD. <?xml version=”1.0” encoding=”UTF-8” ?> <!DOCTYPE HTML PUBLIC “-//W3C//DTD HTML 4.01 Transitional//EN”> <html> XSLT 283 <head> <title>Hello!</title> </head> <body> <h1>Hello!</h1> <p> <img src=”blah.gif” id=”my_picture” name=”my_picture” alt=”blah blah blah”/> <br/> Hi! This is my home page. I want to tell you a few things. </p> <ul> <li>I like playing on the Internet</li> <li>I just want to dance!</li> <li>I wok in the would</li> </ul> <p> That’s about all <br/> I have for now. <br/> </p> <hr noshade=”noshade” /> <p> <b><i>Later!</i></b> </p> </body> </html> If you want compliance with strict XHTML, then you simply need to remove the deprecated attributes and add the namespace attribute to the HTML element. The following file is in compliance with Strict XHTML. <?xml version=”1.0” encoding=”UTF-8”?> <!DOCTYPE html PUBLIC “-//W3C//DTD XHTML 1.0 Strict//EN” “http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd”> <html xmlns=”http://www.w3.org/1999/xhtml” xml:lang=”en” lang=”en”> <head> <title>Hello!</title> </head> <body> <h1>Hello!</h1> <p> <img src=”blah.gif” id=”my_picture” alt=”blah blah blah”/> <br/> Hi! This is my home page. I want to tell you a few things. </p> <ul> <li>I like playing on the Internet</li> <li>I just want to dance!</li> 284 Chapter 12 <li>I wok in the would</li> </ul> <p> That’s about all <br/> I have for now. <br/> </p> <hr/> <p> <b><i>Later!</i></b> </p> </body> </html> Compliance with Transitional XHTML is more than enough to ensure compatibility with XSLT. The advantage of Strict compliance is that you are fully compatible with the latest version of XHTML. However, there is a price for this compatibility: Because you aren’t allowed to use deprecated attributes, you lose some backward compatibility. Tips and Tricks of Migrating HTML If you have a lot of old HTML that you want to make into stylesheets, you may be brac- ing yourself for a daunting task. Not to worry—there are many ways to make the transition easy. First and foremost, your stylesheets don’t have to be fully XHTML compliant. They just have to be XML compliant. Because you have to do some work anyway, there is a strong argument that you might as well bring them fully up-to-date and make them XHTML compliant. Our first tip shows you how to bring your old HTML into XML compliance by just using the XSLT processor. From there, some XHTML tools and validators will be discussed. Your first step should be to get Dave Ragget’s Tidy utility. It will automatically con- vert most HTML, even really messy HTML, to well-formed XML. You can locate the utility by going to either of these URIs: http://www.w3.org/People/Raggett/tidy/ http://tidy.sourceforge.net/ After installation you can run the tool as follows: Tidy —output-xhtml yes —indent yes MyOld.html > LikeNew.xhtml You can then run a document through the validator at validator.w3.org. Simply put the file on a public Web site, navigate to validator.w3.org, and type in the URI. You should have one of the XHTML DTDs in place to make sure it is valid XHTML. From there, your next step is to transition it to a stylesheet. Here is the process: 1. Get rid of any DOCTYPE instructions. 2. Add xsl:version=”1.0” as an attribute/value pair to the html element. 3. Save the file as a stylesheet with the .xsl extension. 4. Create a dummy XSQL file that references the stylesheet. XSLT 285 Figure 12.3 XSLT error. The dummy XSQL file doesn’t need to contain any actual SQL queries. In fact, it should be as simple as possible. This is just a way to check and make sure that the Oracle XSLT Processor likes your file. The following will do great: <?xml version=”1.0”?> <?xml-stylesheet type=”text/xsl” href=”my_stylesheet.xsl”?> <page> </page> If your file is okay, the XSLT processor is just going to display the page to the browser. After all, there is no actual XSLT code that needs to be processed. However, if there is a problem with your stylesheet, then the translator will report an error back to you. Figure 12.3 shows an example. The error was generated by using the original ugly HTML example that appeared previously. If nothing else, you can use the XSLT processor to iteratively fix your HTML, line by line. Moving On This chapter gave you a high-level overview of XSLT, which should have comple- mented the earlier examples that used XSLT. Chapter 13, “XSLT In-Depth,” covers the details of coding XSLT. Because XSLT controls how your XSQL application looks, it’s an important part of your overall code. You’ll see this in Chapter 14, “Building XSQL Web Applications,” when you create your own application. A lot of the overall code is XSLT stylesheets. 286 Chapter 12 287 This section details all the elements in XSLT based on what they do. It is meant as a tutorial on the first reading and then a quick reference after that. It starts with the root element and then introduces all the elements, including their syntax and examples. The following XSQL is used for all the examples in this section. It produces the data for the employees in the emp table. To use the examples in this section, be sure to change href to whatever name you give the stylesheet. <?xml version=”1.0”?> <?xml-stylesheet type=”text/xsl” href=”some-stylesheet.xsl”?> <page connection=”demo” xmlns:xsql=”urn:oracle-xsql”> <xsql:query> SELECT * from emp </xsql:query> </page> At this point in your reading, it is assumed that you know how XSLT stylesheets fit in with the rest of the XSQL framework. In general, a datagram is returned from the database and in the canonical format, and you use an XSLT stylesheet to transform it into something useful to the client. With certain actions—xsql:insert-request, xsql:update-request, xsql:delete-request, and xsql:insert-param— you can also transform the input using an XSLT stylesheet. From there, you’ll learn about the selection of values from the inputted XML document. XSLT In-Depth CHAPTER 13 This chapter looks at all the details of using XSLT stylesheets. You’ll learn about all the XSLT elements, as well as XPath, which allows you to search locate nodes in the inputted XML document. The first discussion concerns the root element; the next discussion shows you how to control the output with the xsl:output element. From there, you get into the core of XSLT—templates. You can’t really write a simple example without using templates, so you’ve seen them before. In Chapter 14, you’ll get a chance to apply your knowledge learned here to a real-world application. Also in that chapter, you’ll see how to iterate through sets of nodes and how to use conditional logic. From there, you’ll learn about the rest of the XSLT elements, in addition to how to create XML entities and handle special cases with text, how to number elements, how to deal with variables and parameters, how to reuse stylesheets, how to sor, and how to handle whitespace. The chapter concludes by looking at whitespace. Root Element A stylesheet is an XML document; thus it requires a root element. The XSLT specifica- tion says that the root element should be either xsl:stylesheet or its synonym, xsl:transform. In practice, the Oracle XSLT processor will accept any element as the root element as long as the attributes required of the xsl:stylesheet element are attributes of the root. This section looks at the syntax of the root element and pro- vides examples. xsl:stylesheet Syntax The xsl:stylesheet element can only be the root element of an XSLT stylesheet. It is completely synonymous with the xsl:transform element. Its attributes describe the stylesheet to the XSLT processor. You can optionally use the html element as the root and simply add these stylesheet attributes to the html element. The syntax of the xsl:stylesheet element is below. A stylesheet element is required to be the root element and only one stylesheet element is permitted per stylesheet. <xsl:stylesheet version = “version_number” xmlns:xsl = “namespace_URI” id = “id” extension-element-prefixes=”extension_prefix_list” exclude-result-prefixes=”exclude_prefix_list”> any xml </xsl:stylesheet> Table 13.1 lists the attributes. 288 Chapter 13 Table 13.1 xsl:stylesheet Attributes ATTRIBUTE DESCRIPTION Version The version of the stylesheet, which should be 1.0. If it is greater than 1.0, forwards-compatible processing will be enabled. This means that the XSLT processor must process the stylesheet with the expectation that new features of XSLT are being used that the processor doesn’t know about. Xmlns:xsl The namespace for the stylesheet. The URL listed should be the namespace. It is not strictly required, though highly recommended. Id An identifier for the stylesheet. Extension-element-prefixes Whitespace-delimited list of namespace prefixes of extension elements used in the stylesheet. Exclude-result-prefixes Whitespace-delimited list of namespace prefixes that should be excluded from the output. The root element can’t have a parent, but it can have the child elements listed in Table 13.2. Any xsl:include or xsl:import child elements must precede all other child elements. Table 13.2 Children of the Root Element CHILD ELEMENT xsl import xsl include xsl attribute-set xsl decimal-format (continues) XSLT In-Depth 289 . In fact, it should be as simple as possible. This is just a way to check and make sure that the Oracle XSLT Processor likes your file. The following will do great: <?xml version=”1.0”?> <?xml-stylesheet. version=”1.0”?> <?xml-stylesheet type=”text/xsl” href=”some-stylesheet.xsl”?> <page connection=”demo” xmlns:xsql=”urn :oracle- xsql”> <xsql:query> SELECT * from emp </xsql:query> </page> At this. the root element should be either xsl:stylesheet or its synonym, xsl:transform. In practice, the Oracle XSLT processor will accept any element as the root element as long as the attributes required

Định dạng
Số trang	20
Dung lượng	230,13 KB