More than a year ago, Mark Smith, editorial director and group publisher for Windows 2000 Magazine, asked me how Extensible Markup Language (XML) might affect Microsoft's Windows Script Technologies. At the time, I replied that XML will certainly play a crucial role in Web-based application development but won't significantly affect the system-administration scripting world. However,Microsoft's Windows Scripting Host (WSH) 2.0 proved me wrong. WSH 2.0 (also called Windows Script 5.1) includes powerful new features that depend on a new file type and format. Care to guess what type of file? Read on.
In "Windows Scripting Host 2.0," December 1999, I introduced you to WSH 2.0's new features (e.g., include-file support, multiple script-engine support, tools support, external-constant access, new runtime options). You might recall that several of the new capabilities hinge on the new Windows Script (WS) file format. WSH 2.0 WS files aren't simple ASCII files that contain VBScript, JScript, or other ActiveX-compliant scripting language code. WSH 2.0 WS files are XML applications that Microsoft structured according to the WS XML schema. The new file type and format provide a significantly improved and powerful scripting framework. Let's examine the WS XML schema and the new features it provides.
New File Extension
WSH 1.0 didn't define a unique file extension for WS files. To name WS files, WSH 1.0 used an extension that an ActiveX scripting engine defined and registered. The VBScript engine registered a .vbs extension, and the JScript engine registered the .js extension. WSH 1.0 used the registered extension to connect a script source file to the appropriate script engine.
WSH 2.0 registers a new extension that XML-based WS files use. Initially, Microsoft used the file extension .ws. Just before the company released WSH 2.0, Microsoft changed the extension to .wsf. Because of this late change, the WSH 2.0 documentation and several WSH-related books and articles refer to the .ws extension. When you leverage WSH 2.0's new XML-based features, your script filename will need to carry a .wsf extension, not the .ws extension. Of course, you can continue to use .vbs or .js extensions to create VBScript or JScript source files.
Extensible Markup Language
You don't need to be an XML guru to leverage the features the new XML-based WS file provides. However, you need to understand a few fundamental XML concepts and how XML fits into the overall WS strategy. Let's first compare XML with the familiar HTML tag language.
Like HTML, XML is a platform-independent industry standard that the World Wide Web Consortium (W3C) manages. (For information about W3C, visit the Web site at http://www.w3c.org/xml.) XML is also a tag language, as is HTML. However, the similarities between HTML and XML end with these two characteristics.
Although XML might look similar to HTML, XML isn't based on a fixed set of predefined tags. Also, XML tags don't control how a Web browser displays text. XML is a metalanguage used to create custom markup languages that can define all types of information or data, such as documents, binary objects, address book entries, financial transactions, or scripts.
XML defines information and data according to purpose rather than presentation so that several applications can use the information and data in ways that promote diverse application reuse and extensibility. Two WS technologies demonstrate the power of XML: Windows Script Components (WSC—.wsc) and WSH 2.0 WS files (.wsf). Microsoft first leveraged XML to define the schema that is the WSC information model. WSC (formerly, Scriptlets) are COM components written in script. When Microsoft enhanced WSH, the company reused much of the WSC XML schema to define the WS file grammar. The enhanced WSH leverages existing XML data definitions in a new and powerful way. Because the two technologies support much of the same XML schema, users essentially learn two technologies for one cerebral investment.
Elements, Tags, Attributes, and Content
The structure of a WS file looks similar to that of an HTML file. Both files include content surrounded by elements made up of angle bracket-enclosed tags and attributes. Figure 1, page 167, shows the basic syntax for elements in the WS file structure.
An element is a pair of identically named tags that constitute a start tag and an end tag. The start tag consists of a left angle bracket (<), followed by a lowercase name that is typically a noun, an attribute list (sometimes optional), and a right angle bracket (>). For example, the start tag <script language="language"> contains the tag name script and one attribute definition, language="language". The end tag is similar to the start tag, except that you preface the lowercase tag name with a slash (/) and exclude any attributes (e.g., </script>). Attributes are mandatory (or optional) named values that provide additional information about the corresponding tag or about the content that follows. For example, <script language="vbscript"> means that the content immediately following this element will be VBScript source code. You lowercase attribute names and include them in the start tag, and you always type attribute values inside double quotes.
To tie this information together, let's examine the WS XML schema that Figure 2, page 168, shows. The XML schema represents the data model that defines the elements and associated attributes an XML application supports. The schema also defines the file structure—the relationship between the elements, which elements can nest inside others, and the sequence in which the elements can appear. The schema can optionally define default values for attributes.
The example in Figure 2 shows that the <package> element can contain one or more <job> elements and the <job> element can contain one or more <object>, <reference>, or <script> elements. Of these five elements, <job> and <script> are the only mandatory elements that you need to create a WS file script. In the example in Figure 2, the <object> and <reference> elements and the first instance of the <script> element don't have matching closing tags because these elements are empty-element tags (i.e., they have no content). You use a slash (/) just before the closing angle bracket to terminate empty elements.
In Figure 2, the XML declaration and CDATA section are standard W3C XML 1.0 markup that affect how the parser handles your WS file script. Two modes of parsing are available—loose and strict. Loose parsing is less stringent because the parser doesn't enforce standard XML rules such as case sensitivity or double-quoted attribute values. Loose parsing also assumes that everything between the <script> and </script> tags is source code and that nothing even closely resembling XML appears inside the script block. However, you can experience problems when your source code contains an XML reserved word or symbol (e.g., a less-than sign—<—or a greater-than sign—>) because the parser will complain and your script will abort. To remedy the situation, you can include the XML declaration on the first line of your WS file script to force the parser into strict mode. If the parser is in strict mode, you must closely follow the standard XML rules and enclose your source code in a CDATA section. When you use this remedy, you escape the entire script block so that strings or characters that the parser might otherwise recognize as valid XML won't cause your script to bomb.
Windows Script File Grammar
Now that you understand the primary permissible WS file script elements and structure, you're ready to examine the syntax, definition, and usage of each element. Table 1, page 168, provides a detailed description of the WS file elements, and Table 2 examines a few good-to-know standard W3C XML 1.0 tags. Turn to Scripting Solutions next month, and I'll put all this new XML information to work in a Windows Management Instrumentation (WMI)-based event-log utility that demonstrates the power and flexibility behind the WS file.
