- Shopping Bag ( 0 items )
That's where Developing ASP Components, 2nd Edition, comes in. Its first section explores the topics everyone needs to know to develop effective ASP components:
ASP components are language independent, and developers increasingly tend to use more than a single language tool. Thus the remainder of the book focuses on ASP component development using one of two major development tools—Microsoft Visual Basic and Microsoft Visual C++ (with the ActiveX Template Library)—along with a number of other languages, such as Perl and Delphi. Each section focuses on the issues that concern the ASP component developer using that particular development environment. These issues include:
It's this strong focus on two major development environments, along with a thorough grounding in essential ASP topics, that makes Developing ASP Components, 2nd Edition, the definitive resource for the ASP application and component developer.
In this chapter:
Working with XML in ASP Applications
XML and ADO: Saving Recordsets as XML
There are few technologies that have excited developers as much as XML--Extensible Markup Language. I've heard people talk about XML as a replacement for everything from HTML to SQL. If you view available jobs on the Internet, you'll find few having anything to do with web applications that don't also mention the use of XML in some capacity.
ASP application developers are not immune to the lure of XML, yet there is confusion about how XML can be used with a server-side technology such as ASP, especially when writing ASP components.
This chapter provides an overview of XML, as well as XML formatting techniques, because it's necessary to have an understanding of XML before working on the examples in the second part of the chapter. These examples and their related discussions cover working with XML in ASP components written in Visual Basic. Some of the examples we'll look at include accessing and creating XML through the Microsoft XML parser (MSXML), working with XML through ADO, and mixing ASP processing with XML content.
TIP: XML is a recommended specification from the World Wide Web Consortium, otherwise known as the W3C. You can access the specification at the W3C web site at http://www.w3.org.
XML is a simple-to-use basic markup language that is a subset of the more complex SGML--or Standard Generalized Markup Language. The specification was created primarily due to insufficiencies of the HTML standard and particularly the difficulties inherent in introducing a new element into the HTML standard.
For instance, mathematicians have a unique professional grammar and syntax that they use to describe their work, but there are no tags within the HTML specification that could be used for this effort. However, to expand HTML just for mathematicians--or musicians, physicists, and so on--isn't efficient.
This problem became very apparent when Netscape began to introduce elements into its rendering of HTML--elements such as
FONT for defining font characteristics. By introducing new elements outside of the HTML specification, pages that were created to work with Netscape Navigator didn't work well with Internet Explorer or other browsers.
Another limitation of HTML is that there is an assumed presentation and layout associated with the elements in an HTML document, but not all rendering engines (browsers) provide identical element presentations. The HTML standard just doesn't provide a means of defining every aspect of how an element is shown on the page. A problem associated with combining presentation as well as content within the same specification is that the specification can either become overly large and complex, or pages created using the specification don't always look the same across different browsers, different operating systems, or both.
XML was created as a solution to both of these HTML limitations.
First, XML is a way of creating a document that can contain an arbitrary set of elements--defined with unique element tags--but still be accessible to document parsers that weren't created specifically to work with the page's elements. The reason that parsers can process the page is that the page and the elements follow a specific set of rules.
Secondly, there is no presentation or layout associated with XML elements. This is provided, instead, by separate standards, specifically by Cascading Style Sheets (CSS) or Extensible Stylesheet language (XSL). Separating presentation from content enables anyone to create their own set of XML elements, provide their own presentation with CSS or XSL, and have the page appear the same regardless of what browser parsed the page.
TIP: This chapter barely touches on the subjects of the XML, CSS, and XSLT specifications--just enough to introduce the examples. For more detailed information, check the XML SDK that's available at the Microsoft web site at http://msdn.microsoft.com/xml.
One reason XML has become so popular is that it's relatively easy to understand the rules governing this markup language. By following the rules, a web developer creates a "well-formed" document that can be parsed by any XML parser, including those built into browsers such as IE, Mozilla, and Navigator 6.0. When the rules aren't followed, the parser can't process the document, and an error results--the parser does not attempt to recover from the error.
TIP: Another problem with HTML parsers is that they can be very forgiving at times, and web page developers have developed some bad habits as a consequence. A case in point is people using opening tags such as the paragraph (
<P>) or list (
<LI>) tag in their document but without providing a closing tag for the content.
The first line of an XML document can contain the XML declaration, though this isn't required:
<? xml version='1.0' ?>
This line consists of the XML document tag, in addition to the version of XML used in the document. At this time, there is only one version of XML, but you should use the 1.0 version number to differentiate the XML used in the document from future versions of XML.
The XML declaration can also include the character encoding used in the document, such as UTF-8 or EUC-JP. Not all XML processors can process all encodings, and an error results if you use an encoding the processor doesn't recognize.
All XML elements must either be empty tags or have both beginning and closing tags. For instance, if your XML document has an element such as the following, with attributes but no content, then the element must be defined as an empty tag and have a forward slash at the end of the element:
<template attribute="process" />
If your element defines content, then you'll need to use both a beginning and an ending element tag:
Not providing either the forward slash for an empty tag or the closing tag results in an XML processor error.
Another XML rule is that any Document Type Definition (DTD) files or rules must be specified before any other element in the document. DTDs provide grammar or additional application-specific rules that can be applied to the XML document. Though not required, providing a DTD file makes the XML document valid as well as well-formed:
<!DOCTYPE template SYSTEM "template.dtd">
An additional rule for the XML document is that the elements contained in it must not overlap. This means that you can nest elements, but a nested element must be closed with the appropriate closing tag (or be an empty tag) before the closing tag of the outer element is reached:
Overlapping elements result in an XML processor error.
XML is case-sensitive, so the case used for the opening tag of an element must match the case used for the closing tag. Otherwise, again, an XML processor error results.
Additionally, there are certain characters that should not be used within attribute values or content, characters such as angle brackets (< and >) or the ampersand (&). These characters have special meaning in XML, just as they do in HTML documents.
Other rules are that element attributes must not repeat within a tag, and they must not reference external entities.
Earlier I mentioned that an XML document with an associated DTD file is considered a valid document. The reason for this is that the DTD file provides the grammar and rules to validate the XML used in the document.
For instance, if an element can contain data, a rule could be added to the DTD file for the XML document, similar to the following:
<! ELEMENT template (#PCDATA)>
As efficient as DTD files are, a problem with them is that the syntax used to define the document grammar differs from the syntax for the XML documents, forcing a person to become familiar with two syntaxes. Efforts are underway to define XML schemas to provide for XML entity and attribute descriptions. XML schemas, unlike DTD files, use XML to describe the XML data.
XML is first and foremost extensible. This means that more than one set of XML elements for more than one purpose could be included within the same XML document. However, if the same element name is used with two differing components, you have element collision. To prevent something like this from happening, the W3C provided the XML Namespaces specification in 1999.
Namespaces are identified with URIs and are then used as an alias for elements and element attributes within that namespace. With this approach, a document can contain elements from several difference namespaces, and though the names of the elements are the same, the namespaces prevent collision.
For instance, a namespace could be defined with the following:
And used as is shown in the following:
No document needs exist at the namespace URI--the URI itself is the key to defining the namespace.
XML by itself has no presentation or formatting information associated with it. It's used to define elements and their relationships with each other (as in container and contained). Other W3C-recommended specifications are then used to provide formatting, layout, and presentation information about the XML document elements....