Introduction to XML Technologies


XML is a hot topic among system developers ” especially the designers of Windows and Office. Applications developers, including those who create solutions with Access and the other Office packages, typically are in the early stages of learning about XML and the benefits it can bring to their solutions. A reason for this distinction between system and application developers may be the rapid proliferation of XML technologies and a lack of appreciation of how to use those technologies from Access and the other Office solutions. Access 2003 is XML-oriented and should help Access application developers to start using XML to enhance the solutions that they create for clients .

This section introduces three XML technologies that you can use with Access 2003 and other packages in Office 2003. First, this section examines XML document syntax. Knowledge of this syntax will help you read and process XML documents that can contain Access data. Second, the section shifts the focus to XSD schemas. XSD stands for XML Schema Definition. The XSD schema is an industry standard for specifying the structure of XML documents. For example, you can designate the data types for values in an XML document, as well as specify the primary key for an XML document based on an Access table. XSD schemas are XML documents, except their content is a statement about the structure of another XML document containing data. Third, the section acquaints you with XSLT, a language for manipulating the format of XML documents via style sheets and transformations. XSLT is based on XML syntax.

The following URL takes you to an especially useful reference within MSDN with a description of MSXML 4.0: http://msdn.microsoft.com/library /default.asp?url=/library/en-us/xmlsdk/htm/xslt_starter_78s4.asp . The site provides a thorough review of XML technologies, including starter kits for XML, XSD schemas, and XSLT.

The World Wide Web Consortium (W3C) is the premier destination for publications defining standards for XML and its related technologies. To learn more about the wealth of resources available from the W3C, go to its home page ( http://www.w3.org /) and browse the list of technologies on its left border.

XML Document Syntax

XML is a text-based format for representing data. The data can be from Access databases, Excel workbook files, and Word documents, plus many other sources. XML documents are powerful because of their flexibility. Like HTML, XML embeds content within tags. XML syntax offers a hierarchical system for representing the content of documents. However, because you can specify your own tags, XML is adaptable to any source material. Also, XML has more rigid syntax conventions than those for HTML. These syntax conventions provide the basis for a consistent set of rules for retrieving content from an XML document, even when the tags used in one document are radically different from the tags used in another document. When a document follows the syntax rules, XML literature refers to the document as well-formed. For an XML parser to read an XML document, it must be well-formed. Microsoft Internet Explorer browsers include parsers for XML documents. If you attempt to view an XML document that is not well- formed , the browser reports an error in the document syntax. Otherwise, you will see the XML document contents in Internet Explorer.

Note  

Unless you are going to author XML documents from scratch, you do not need to know the rules for constructing a well-formed document. Those seeking a precise definition of what makes an XML document well-formed can find it at http://www.w3.org/TR/2000/REC-xml-20001006#dt-wellformed .

An XML document consists of declarations, tags, and attributes. In the declaration area, which is sometimes called the prolog, you declare a document to be consistent with a specific version of XML syntax. The current XML version is 1.0. You can also specify namespaces and other references that help to refine the definition of an XML document. For example, the prolog can denote namespaces that define tags used in an XML document. You can also denote a schema that specifies structure for the content in an XML document. Additionally, you can designate an XSLT file that includes code to reformat the representation of the data in an XML document.

You can represent data values within an XML document with tags that define elements and attributes that function similarly to properties for elements. An element nearly always has a start tag and an end tag. A start tag embraces the element's name in angle brackets ( < elementname > ). Between any start tag and end tag, you can include the text representation for a value. You can denote the element's end tag with a forward slash just before the element name ( </ elementname > ). Start and end tags can occur one or more times within a document. An XML document requires a root set of tags ”one just after the declaration and prolog for a document and the other as the last tag in the document. If the outermost start and end tags with data occur just once, then these tags satisfy the requirement for a root set of tags. Otherwise, you can specify another element with an arbitrary name to serve as the root element for the XML document. The other elements nest within the root element. XML syntax permits multiple levels of element nesting within an XML document. This nesting feature is one of the strengths of XML data representations. In ADO, you represent a join between customers and orders as a single rowset. In XML, you can represent the orders for a customer nested within that customer. This nesting better represents the internal structure of the data.

The following document, which is available as MyShippersWithElements.xml in the companion content for this chapter, shows a representation of the values from the Shippers table in the Northwind.mdb file with tags denoting elements. All other XML documents created for this chapter are also available in the companion materials for the chapter. You can create and edit a document such as MyShippersWithElements.xml from your favorite text editor (I like Notepad.exe). The declaration in the first line designates the document as an XML document version 1.0. The starting <dataroot> tag has a matching tag ( </dataroot> ) on the last line of the document; <dataroot> and </dataroot> are the root tags for the document. Within the dataroot element are three repeating Shippers elements. Nested with each Shippers element are a set of elements containing column values from the Shippers table.

 <?xmlversion="1.0" ?> <dataroot> <Shippers> <ShipperID>1</ShipperID> <CompanyName>SpeedyExpress</CompanyName> <Phone>(503)555-9831</Phone> </Shippers> <Shippers> <ShipperID>2</ShipperID> <CompanyName>UnitedPackage</CompanyName> <Phone>(503)555-3199</Phone> </Shippers> <Shippers> <ShipperID>3</ShipperID> <CompanyName>FederalShipping</CompanyName> <Phone>(503)555-9931</Phone> </Shippers> </dataroot> 

Attributes also facilitate the representation of data values in an XML document. Recall that you can think of attributes as properties of an element. You designate attributes as name-value pairs. An equal sign delimiter (=) separates the name from the value and attribute values must appear within quotation marks. The convention is to use double quotation marks, but single quotation marks are also acceptable. It is most common to see single quotation marks as attribute value delimiters when the value contains one or more double quotation marks within it. The MyShippersWithAttributes.xml document that follows shows the syntax for using attributes to represent the values in column values from the Shippers table, which is the same source for the preceding XML document.

This XML document sample also illustrates how to close an element without a distinct end tag. Notice that the start Shippers tag with the column values for each of the first two Shippers elements ends with a closing slash. This closing slash represents the end tag. The third Shippers element in the document shows the syntax with a distinct closing tag for the element. Either design practice is acceptable.

 <?xmlversion="1.0" ?> <dataroot> <ShippersShipperID="1" CompanyName="SpeedyExpress"  Phone="(503)555-9831" /> <ShippersShipperID="2" CompanyName="UnitedPackage"  Phone="(503)555-3199" /> <ShippersShipperID="3" CompanyName="FederalShipping"  Phone="(503)555-9931" ></Shippers> </dataroot> 

Figure 15-1 shows the MyShippersWithElements.xml and MyShippersWithAttributes.xml documents in a browser. The Internet Explorer browser has a built-in XML document viewer, which is based on its parser for XML syntax. Notice that the viewer automatically indents nested elements. For example, the Shippers element is indented relative to the dataroot element. Within the MyShippersWithElements.xml document, the ShipperID , CompanyName , and Phone elements are indented for each Shippers element. This indenting feature with Internet Explorer improves the clarity of a document's structure relative to viewing the same document in a basic text editor, such as Notepad. On the other hand, Internet Explorer does not enable the editing of an XML document unless you invoke the View, Source command, and save your changes. However, when choosing View, Source from a browser, the document's tags appear without any automatic indenting. Notice that elements in an XML document that have other elements within them appear with expand/contract controls to their left. All the controls in Figure 15-1 are fully expanded so they appear with a minus sign (-). However, you can collapse the nested elements by clicking the control. In a collapsed state, the control appears with a plus sign (+). The Internet Explorer XML document viewer converts all rows in MyShippersWithAttributes.xml document to a format with an embedded end tag, instead of the mixed use of the embedded end tag for the first two rows and an explicit end tag for the last row (as in the original document).

click to expand
Figure 15.1: The MyShippersWithElements.xml and MyShippersWithElements.xml documents in a browser.

There are many other features you could learn about XML documents. I highlight three aspects of XML document syntax that should improve your ability to read the XML documents that you encounter. In addition, you can use these guidelines to create your own XML documents.

By now you should have the idea that formatting an XML document is a lot like programming. Therefore, there are tags for marking text as a comment in a document so that it is readable to the human eye, but it is not parsed along with the rest of the text in a document. There are two common uses for the block comment marker. First, to add a comment to a document that provides information about its purpose, author, original date, or similar kind of content. Second, you can bound regular content in block comment markers to remove the content from the parsed version of a document. This is helpful for debugging the document's structure. The syntax for a comment marker appears next .

 <!texttobecommentedoutofadocumentcanbeon1+lines 

There are five special characters that are routinely represented by escape sequences in XML documents. These characters have special meaning to the parser. Therefore, using the escape sequence allows you to designate one of the characters without having the parser misinterpret your content. For example, the open angle bracket (<) denotes the start of a tag, but it also represents the less than sign. If you mean the less than sign, then you should use the special escape sequence (&lt;) rather than the open angle bracket (<). The following table shows the five escape sequences you can encounter in XML documents.

Meaning

Escape sequence

< (less than)

&lt;

> (greater than)

&gt;

& (ampersand)

&amp;

' (apostrophe or single quotation marks)

&apos;

" (double quotation marks)

&quot;

CDATA sections are another formatting convention that you are likely to discover in some XML documents. Like the escape sequences in the preceding table, CDATA sections enable you to represent any special markup characters in an XML document so that the parser does not interpret them as standard markup. The difference is that a CDATA section applies to a whole block of code rather than a single character. In this sense, a CDATA section acts like an element in an XML document. In addition, you do not need to use escape sequences for special characters, such as <. The start of a CDATA section is indicated with <![CDATA[ . Denote the end of a CDATA section with ]]> . Nothing between the starting and ending delimiters is parsed by an XML reader. Instead, it passes through as is. A CDATA section cannot include its start nor its end delimiters. In addition, there are no escape sequences to represent them.

The SpecialMarkupSamples.xml file illustrates the syntax for representing special characters with either escape sequences or a CDATA section. The document also illustrates the syntax for a block comment marker. Figure 15-2 shows the document in a browser.

 <?xmlversion="1.0" ?> <dataroot> <!--examplewithescapesequence--> <message>a&lt;b</message> <!--examplewithCDATAsection--> <![CDATA[a<b]]> </dataroot> 
click to expand
Figure 15.2: Either escape sequences or CDATA sections can be used to represent special markup characters in an XML document.

XSD Schemas

Recall that a schema specifies the structure of an XML document. Since an XML document can reflect a table from an Access database file, you can think of a schema as a table definition that you see in the Design view for a table. The difference is that Design view represents the table through a graphical UI and the XSD schema reflects the structure of the document in XML code. Yes, the language for expressing XSD schemas is XML. This feature is one of the strengths of XSD schema versus alternative means of representing the structure of XML documents.

As you spend time learning about XML, you are likely to encounter three different formats for describing the structure of an XML document. A Document Type Definition (DTD) is an early way of representing the structure of XML documents that differs from schemas. The language for expressing DTDs is Extended Backus-Naur Form (EBNF). It is not important that you know more about EBNF other than that it is not XML. This means that document authors have to master another language just to express the structure of their XML documents. In addition, DTDs are not smart about the demands of a database, such as a rich data type structure. Schemas get around both of these weaknesses of DTDs and add other benefits, such as easy extensibility and self-documenting capabilities.

There are actually two types of schemas for XML documents. Microsoft took the initiative in defining a schema model for XML documents before the formal approval of a standard by the W3C. This early implementation of schemas for XML documents has the name XDR schema for XML-Data Reduced schema. Microsoft implemented this early schema in Internet Explorer 5 and version 2.0 of Microsoft XML Core Services (MSXML 2.0). Shortly after the W3C adopted a standard for expressing XML schemas in XSD language, Microsoft switched its support to XSD schemas. The XSD schema standard is implemented in MSXML 4.0 and Internet Explorer 6.0.

Note  

Subsequent to the release of MSXML 4.0, Microsoft released MSXML 5.0, which added support for inline XSD schemas in XML documents instead of requiring a separate XSD schema file from the structure of the XML document that it supports.

When working with XML documents and Access, your XML documents will typically refer to three external schemas. The standard schema for all XML documents is the W3C XSD schema standard at http://www.w3.org/2001 /XMLSchema . XML documents created with Access typically refer to a schema with a URN (Uniform Resource Name) of schemas-microsoft-com:officedata . URNs specify the name and source for a document rather than the exact location of a resource on the Web as with a URL. In addition, your schema will contain information derived from the Access database object, such as a table, query, or form that serves as the basis for an XML document. The schema name frequently is the same as the XML document, except that its file has an .xsd extension instead of the .xml extension used for the XML document.

Figure 15-3 shows an XML document based on the Shippers table in an Internet Explorer browser. This document was generated through the Access UI. The Shippers table was imported, along with the Customers and Orders tables, to the Chapter15.mdb file from the Northwind.mdb file. The <dataroot> tag is immediately after the declaration tag for the XML document. Within the <dataroot> tag, three attributes point to XSD schemas for the document. These schemas can define elements and attributes in the remainder of the Shippers.xml file. The Shippers.xsd schema file appears in the same folder as the Shippers.xml document file. You can refer to schemas in other folders and at Web-based URLs as well. To refer to a file-based URL, use the following format: file://DriveLetter:// path /filename.fileextension .

click to expand
Figure 15.3: The Access UI creates XML documents that use attributes in the root tag for an XML document to refer to XML schemas.

The attributes in the dataroot denote namespaces. In XML, namespaces are collections of pre-defined tags and attributes. Generally, you point a reference to a namespace with the xmlns:namespaceprefix , such as xmlns:od to point at the shemas-microsoft-com:officedata namespace. If any item (tags or attributes) in the XML document explicitly represents types from the schemas-microsoft-com:officedata namespace , then you should precede the item with the prefix representing the namespace, which is od in this case. You can designate a default namespace of schema types by using the xsi:noNamespaceSchemaLocation attribute. The namespace at http://www.w3.org/2001/XMLSchema-instance is the implementation of the W3C XSD Schema standard. The xsi:noNamespaceSchemaLocation attribute points at the location of the XSD schema file to look up any element or attribute in a document that does not have a prefix. It is normal for XML documents created with the Access UI. You will sometimes find a namespace for a custom schema referenced with the xsi:schemaLocation attribute, instead of the xsi:noNamespaceSchemaLocation attribute. Documents that always use a namespace prefix before tags and attributes in an XML document require this attribute for pointing at a custom XSD schema.

Authoring XSD schemas can be detailed work that is easily subject to error. Access developers are not likely to be writing their own schemas, and Access 2003 has no built-in tools to simplify the task. An Access developer is more likely to read a schema to understand the structure of the contents within an XML document. The following listing shows the XSD schema, Shippers.xsd, for XML document Shippers.xml depicted in Figure 15-3. Like the XML document, the XSD schema was created automatically for the Shippers table with a few clicks in the Access UI. Viewing the schema in a browser improves its readability by automatically indenting nested elements. When working with a schema listing from Notepad, such as the one that follows, I often draw connecting lines on the left edge of a listing between matching tags to improve the readability of a schema document.

 <?xmlversion="1.0" encoding="UTF-8"?> <xsd:schemaxmlns:xsd="http://www.w3.org/2001/XMLSchema"  xmlns:od="urn:schemas-microsoft-com:officedata"> <xsd:elementname="dataroot"> <xsd:complexType> <xsd:sequence> <xsd:elementref="Shippers" minOccurs="0" maxOccurs="unbounded"/> </xsd:sequence> <xsd:attributename="generated" type="xsd:dateTime"/> </xsd:complexType> </xsd:element> <xsd:elementname="Shippers"> <xsd:annotation> <xsd:appinfo> <od:indexindex-name="PrimaryKey" index-key="ShipperID "  primary="yes" unique="yes" clustered="no"/> </xsd:appinfo> </xsd:annotation> <xsd:complexType> <xsd:sequence> <xsd:elementname="ShipperID" minOccurs="1" od:jetType=" autonumber" od:sqlSType="int" od:autoUnique="yes" od:nonNullable="yes"  type="xsd:int"/> <xsd:elementname="CompanyName" minOccurs="1" od:jetType=" text" od:sqlSType="nvarchar" od:nonNullable="yes"> <xsd:simpleType> <xsd:restrictionbase="xsd:string"> <xsd:maxLengthvalue="40"/> </xsd:restriction> </xsd:simpleType> </xsd:element> <xsd:elementname="Phone" minOccurs="0" od:jetType="text"  od:sqlSType="nvarchar"> <xsd:simpleType> <xsd:restrictionbase="xsd:string"> <xsd:maxLengthvalue="24"/> </xsd:restriction> </xsd:simpleType> </xsd:element> </xsd:sequence> </xsd:complexType> </xsd:element> </xsd:schema> 

There are two broad design features worthy of your attention in the XSD schema that shows in the listing for Shippers.xsd. First, the schema is obviously an XML document. Therefore, learning about XSD schema can build on the knowledge that you already have about XML syntax. Second, the XML document defining the schema uses prefixes for tags and attributes. In this case, the schema uses two standard collections of types denoted by xsd for the W3C schema standard and od for the contents of the schemas-microsoft-com:officedata URN.

The preceding schema listing defines two complex types. A complex type is a type that references at least one other type for a tag or an attribute. The first type or element is the dataroot type. This type builds on two other types ”the Shippers element and the generated attribute type. The Shippers type is a complex type that nests within the dataroot type, whose tag is the root tag for the Shippers.xml document. The schema's structure allows an unlimited number of Shippers elements ( maxOccurs="unbounded" ) within the dataroot element. However, the schema specifies that a Shippers element is not required ( minOccurs="0" ) for the XML document to be valid. The generated attribute is formatted with a native dateTime data type from the W3C standard for XSD schemas; notice the xsd prefix for the dateTime data type name.

The Shippers element definition includes several sections. First, it defines the primary key for the document within the appinfo element. The tag structure for this process is interesting because appinfo has an xsd prefix, but the index element, nested within the appinfo element, has an od prefix. In addition, the index element has a series of attributes that should be familiar to most experienced Access developers, except for one ” clustered . This attribute applies exclusively to SQL Server databases, and its availability confirms that you can create XML documents based on an Access project referencing a SQL Server database containing one or more tables. The clustered attribute is true when the rows are physically sorted on a storage device in the order of the primary key or index.

The Shippers element is complex because its definition depends on several other elements, including but not restricted to the index for the document's primary key. Three of these other elements are the ShipperID , CompanyName , and Phone elements. These element definitions appear within <xsd:sequence> and </xsd:sequence> tags. These tags maintain the order of the elements in the XML document according to their order in the XSD schema. Other XSD schema elements operate on groups of nested elements differently, such as allowing just one element from a group to appear in a document ( choice ) or allowing all nested elements to appear in any order ( all ). The definitions for the ShipperID , CompanyName , and Phone attribute have both od:JetType and od:SQLType attribute specifications, which again confirms that you can create schema for XML documents based on Jet as well as SQL Server databases. In fact, the schema is interpretable by an Access database file pointing at a Jet database or an Access project pointing at a SQL Server database. The three elements ( ShipperID , CompanyName , and Phone ) have minOccurs attribute settings, which in this context specify whether an element value is required for a Shippers element. A value of 1 denotes a required value, and a value of 0 indicates an optional value. Both the CompanyName and Phone element definitions include an xsd:Simple element for defining a special constraint. In this case, the number of characters in the text field.

XSLT

One of the advantages of XML documents is that you can read them without a special reader. After all, the data is in text format. This is not true for either Jet or ADO. In spite of the inherent readability of XML, the actual format of the text values is often awkward to read. This is where XSLT can come in handy. With XSLT, you can select, transform, and reformat the layout of values from an XML document.

XSLT is a rule-based programming language that is XML-based. This means that the XML knowledge that you acquired in the prior reviews of XML documents and XSD schemas applies to XSLT as well. XSLT is a reasonably rich programming language, and it is distinct in syntax and operation from most languages that Access developers know already. Therefore, it represents special challenges as you add it to your suite of tools. Nevertheless, there are some easy opportunities to adapt XSLT in Access applications.

As you begin to migrate to XSLT, I urge you to think in terms of recycling and tweaking XSLT code samples that do much of what you want done. This section demonstrates this approach. First, I describe and demonstrate the operation of a Hello, World! sample from the MSDN site ( http://msdn.microsoft.com /library/default.asp?url=/library/en-us/xmlsdk/htm/xslt_starter_2uhw.asp ). Then I adapt and extend the sample to illustrate how you can modify its output and run it from an Access form. While this demonstration is not based on a database, it does show you how to use XSLT with an Access form. In the "Programmatically Using XML from Access 2003" section, I will revisit XSLT and show you how to programmatically format Access tables for output in HTML pages. The sample in this section even opens the HTML page automatically.

Note  

The samples developed for this section, as in most of the rest of the book, were tested and evaluated with Windows XP and Internet Explorer 6. This combination makes MSXML 4.0 available. XSLT relies on parsing capabilities provided through MSXML 4.0. It is recommended that you deploy MSXML 4.0 before attempting to run the samples in this section.

Presenting and Demonstrating the Hello, World! XSLT Sample

When reformatting an XML document with XSLT, you will need a target XML document to transform and an XSLT program to implement the new format. In addition, you need to tell the XML parser that it should use the XSLT program, which typically resides in a separate file from the XML document. The Hello World! sample resides in a couple of files ”hello.xml and hello.xsl.

The hello.xml file appears below. Notice that it has an xml-stylesheet element with an href attribute that points at the hello.xsl file. The syntax for this element is similar to that used for tying an XML document to an XSD schema. In this case, the link is to the file with the XSLT program (hello.xsl). If you commented out the xml-stylesheet element, the file appears in a browser as an ordinary XML file with a comment. However, with the xml-stylesheet element uncommented, the XML file's appearance in a browser is transformed by the hello.xsl file.

 <?xmlversion="1.0"?> <?xml-stylesheettype="text/xsl" href="hello.xsl"?> <hello-world> <greeter>AnXSLTProgrammer</greeter> <greeting>Hello,World!</greeting> </hello-world> 

Figure 15-4 shows the hello.xml with and without commenting for the xml-stylesheet element. The top window in the figure shows the hello.xml with comment markup surrounding the xml-stylesheet element. Notice that the file has just two elements with data values and that the greeter element with a value of An XSLT Programmer appears before the greeting element with a value of Hello, World! The bottom window shows the hello.xml file with the comment markup removed for the xml-stylesheet element. There is no markup for the element values. In addition, the greeting element value appears before the greeter element value. Also, the XSLT formatted version of the XML file adds a new word, from, before rendering the greeter element value.

click to expand
Figure 15.4: The hello.xml file rendered before and after transformation by an XSLT file.

The following script shows the hello.xsl file that transforms the appearance of the XML document from the top window in Figure 15-4 to the bottom window in the figure. Notice that the listing commences with the declaration of an XML document, which confirms that XSLT is an XML-based syntax. The root node for the document with the XSLT program is the xsl:stylesheet element. An attribute for this node points at the W3C XSLT standard. Next, the xsl:template element specifies a template for the overall formatting of the hello.xml file contents. The match attribute for this element points at the hello-world element in the hello.xml file. The template applies to the elements nested within the hello-world element. The template lays out an HTML page. The H1 heading font in the page body formats the greeting element value. Instead of directly referencing the greeter element, the XSLT code applies a template with an apply-template element that designates another template through its select attribute. This attribute points at the greeter template. The greeter template precedes the value of the greeter element with from, and the template also applies an H2 font setting and an italics font style. The xsl:value of element designates a value to display. The element's select attribute specifies the value to display. In this case, the period (.) denotes the template's name, which is greeter .

 <?xmlversion="1.0"?> <xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform" version="1.0"> <xsl:templatematch="/hello-world"> <HTML> <HEAD> <TITLE></TITLE> </HEAD> <BODY> <H1><xsl:value-ofselect="greeting"/></H1> <xsl:apply-templatesselect="greeter"/> </BODY> </HTML> </xsl:template> <xsl:templatematch="greeter"> <DIV><H2><I>from <xsl:value-ofselect="."/></I></H2> </DIV> </xsl:template> </xsl:stylesheet> 

Extending and Running an XSLT Sample from an Access Form

The extension and adaptation of the Hello, World! sample from the preceding section involves a slightly modified XML document (CustomHelloWorld.xml) and a similarly modified XSLT file (CustomHelloWorld.xsl). The XML document and XSLT program replace the greeter element with a corresponding message element. In addition, the called template ( greeter ) is dropped because the application transforms the text before invoking the XSLT program. However, the new XSLT program retains the same formatting for font size and italics. The CustomHelloWorld.xsl file contents appear next.

 <?xmlversion="1.0"?> <xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform" version="1.0"> <xsl:templatematch="/hello-world"> <HTML> <HEAD> <TITLE></TITLE> </HEAD> <BODY> <H1><xsl:value-ofselect="greeting"/></H1> <DIV><H2><I> <xsl:value-ofselect="message"/></I></H2> </DIV> </BODY> </HTML> </xsl:template> </xsl:stylesheet> 

The novel aspect of the extension is the use of an Access form to gather input that, in turn , populates element values. The code behind the form writes out an XML file as a textstream object to a file that holds the XML document (CustomHelloWorld.xml). Before persisting the textstream object to a file, the code inserts the contents of three text boxes on the form (frmWriteXMLToHTMLWithXSLT). A click event procedure for a button on the form opens the CustomHelloWorld.xml file, which displays as an HTML page in the pma11 Web site initially developed in Chapter 14. Figure 15-5 shows the form with some sample content in its text boxes, and Figure 15-6 reveals the page that displays when the user clicks the Show HTML button on the form.

click to expand
Figure 15.5: An Access form used to collect values for writing an XML document.
click to expand
Figure 15.6: A browser displaying the XML document generated by the click event procedure for the button on the form in Figure 15-5.

For me, the magic of this application is in the click event procedure for the button on the form. The writing of a text file is a major factor in conjuring this magic. The text file is in the format of an XML document and reflects the current values in the text boxes. The application achieves this result through the use of the FileSystemObject class. Your VBA project requires a reference to the Microsoft Scripting Runtime to use the FileSystemObject class. The str1 variable contains the script for the XML document. The string expression for str1 copies values of text boxes into the script. Then the procedure uses a FileSystemObject instance ( fso1 ) to persist the tso1 textstream instance that contains the string variable representing the XML document to a text file. The application persists the XML document to CustomHelloWorld.xml at the pma11 Web site. To run this application, you need pma11 on your intranet or you need to designate another Web site that is on your intranet. Before setting the tso1 and fso1 instances to nothing, the procedure invokes the FollowHyperlink method for a URL pointing at CustomHelloWorld.xml. This opens a browser session with the XML document formatted by the XSLT program in CustomHelloWorld.xsl. The complete listing for the click event procedure appears next.

Note  

To make the cmdShowHTML_Click procedure work properly in your computing environment, you probably will need to update the strServer variable value, and perhaps the strWebsite variable value, for a Web server and Web site conveniently available to you.

 PrivateSubcmdShowHTML_Click() Dimstr1AsString Dimfso1AsNewScripting.FileSystemObject Dimtso1AsScripting.TextStream DimstrGreetingAsString DimstrNameAsString DimstrDescriptionAsString DimstrMessageAsString DimstrFilePathNameAsString DimstrServerAsString DimstrWebsiteAsString DimstrURLAsString     'CopytextboxvaluesforinsertioninXSLTcode strGreeting=Me.txtGreeting strMessage=Me.txtYourName& " " &Me.txtDescription     'Copysavedtextboxvaluesintoxmlscript str1= "<?xmlversion='1.0'?> " &_  "<?xml-stylesheettype='text/xsl'href='CustomHelloWorld.xsl'?> " &_  "<hello-world>" &_  " <message>" &strMessage& "</message>" &_  " <greeting>" &strGreeting& "</greeting>" &_  "</hello-world>"     'Savexmlscripttoafile strFileNamePath=_  "C:\Inetpub\wwwroot\pma11\CustomHelloWorld.xml" Settso1=_ fso1.CreateTextFile(strFileNamePath,True) tso1.Writestr1 tso1.Close     'Openbrowsertosavedxmlfile strServer= "cabsony1" strWebsite= "pma11" strURL= "http://" &strServer& "/" &_ strWebsite& "/CustomHelloWorld.xml" Application.FollowHyperlinkstrURL,,True     'Cleanupobjects Settso1=Nothing Setfso1=Nothing     EndSub 



Programming Microsoft Office Access 2003
Programming MicrosoftВ® Office Access 2003 (Core Reference) (Pro-Developer)
ISBN: 0735619425
EAN: 2147483647
Year: 2006
Pages: 144
Authors: Rick Dobson

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net