APPLY XSL TO XML

XML documents are a good choice for transportable data, but may contain more data than is necessary for your application. To retrieve only a portion of the

XML data, you can transform a source XML document into another XML document by using an XSLT transformation. The resulting document does not always have to be XML. In some cases, you use XSLT transformations to create HTML documents.

XSLT is a language for transforming source XML documents into other document formats using XPath or XSLT as the query language. You can use the XslTransform class, which is part of the System.Xml.Xsl namespace to

orchestrate XSLT transformations. To build well-performing XSLT transformations, you can use an XPathDocument as the XSLT data store. If you are working with a DataSet, you can use XmlDataDocument as your source file in a transformation.

To map the XslTransform class to an XSLT style sheet, you can use the Load method. When you execute the Transform method of the XslTransform class, there are several overload options. In the steps that follow, the Transform method writes the XML to a file.

‹ Rename the namespace to ApplyXSL.

› Rename the class name to ApplyXSL.

ˇ Save the file.

Á Add the Main function.

‡ Create an

XslTransform variable.

° Use the Load function to load the style sheet.

· Use the Transform function to transform the XML document using the XSL style sheet.

‚ Press F5 to save, build, and run the console application.

he .NET Framework is Microsoft’s new computing Tplatform designed to simplify application development

in the highly distributed environment of the Internet. Microsoft has put a major effort in revamping the architecture for their component-based solutions. When you create applications on the .NET platform, you find component development tightly integrated with the solutions you build.

Most application development solutions benefit from creating component-based solutions. The .NET platform enables you to take a very simple approach to distributed component-based solutions by using private assemblies.

By using private assemblies, you can reap the benefits of component programming without the headaches of dealing with versions that are not backward-compatible. Also, it is easier to control your component and how those components get versioned into existing deployed applications.

With highly reuseable components, you can create shared assemblies. Shared assemblies give you more control with your components, but for a price. Shared assemblies enable you to share components across applications, to version your component, and to localize components, among other capabilities.

Applications that use components have proven to be an effective way to build applications. For Microsoft, the open standard for component development started in 1993 with the introduction of the Component Object Model, or COM. Microsoft further enhanced COM into a distributed model with DCOM, Distributed COM, in 1996. Used on more than 150 million systems worldwide today, COM is widely accepted and heavily leveraged in enterprise application for many Fortune 500 companies. The most recent version that is integral to Windows 2000 is COM+. COM+ was an integration of Microsoft Transaction Server (MTS) and COM.

COM/COM+ is the backbone for Microsoft’s Distributed interNet Applications (DNA) platform.

Despite Microsoft’s success with DNA, they are evolving to a new framework. With a mature framework, like DNA via COM, there are issues that cannot be properly addressed due to preserving compatability with earlier versions of COM. .NET takes the issues of what COM+ has today and addresses them based on the best of the COM+ runtime and what other competitive component runtimes have to offer.

The .NET platform addresses one of the major issues of DNA applications, DLL Hell. This refers to the problems that occur when multiple applications attempt to share a COM class. COM enables one or more clients to share classes in COM components. When one client application updates an existing COM component that is not backward-compatible with the version already on the machine, the first client breaks when it tries to create a component based on the new class that is not backward-compatible.

.NET addresses the issue of DLL Hell with side-by-side execution of components via use of assemblies. .NET can perform side-by-side execution of components.

Versioning takes on a new meaning with .NET. With COM components, you register a component for reuse by putting several entries into the Windows Registry, a proprietary store where Windows holds application and operating system settings. The entries in the Windows Registry can end up being corrupted by bad development practices, causing applications to fail when calling the component that has corrupted Registry entries.

With .NET, the versioning has more capabilities and is easier to control. .NET uses the version number when determining which build of a class to load. Configuring what build is used is easily configured through the config file, class, for your application. See page 266 to learn about binding a component version in the

AssemblyInfo project file.

The .NET platform addresses the DLL Hell issue with assemblies. Assemblies enable you to register more than one version of the same component on the same machine. Note that the word register does not mean using the Windows Registry. When you register a version, the version resides in the machine’s Global Assembly Cache, or GAC. Items in the GAC are shared assemblies that multiple clients can use. Assemblies that exist in the GAC have a version number assigned to them. When a client calls for a component, the GAC assists in matching the client component request with the correct version of the component, not just the last installed version. With the capability of Global

Assemblies, you can have two versions of the same component running on the same machine, also called side-by-side execution.

The .NET platform considers components not in the GAC as private assemblies and packages them in the client’s application directory. You can also configure your private assemblies to exist in one of the subdirectories of the application directory. You do not have the benefit of sharing private assemblies across multiple machines, but you can deploy them very simply using xcopy, an old command-line utility that enables you to copy multiple files at the same time.

In the .NET platform, you see the use of namespaces for identifying objects. All examples presented in this book illustrate the use of the keyword Namespace in the classes. When you compile a project, you use namespaces to organize the classes defined in the resulting assembly. Assemblies can contain multiple

namespaces, which can in turn contain other namespaces. Namespaces assist in providing uniqueness and simplify references when using large groups of objects such as class libraries. You can use aliases if you want to avoid fully qualifying a class nested in a namespace.

Web Services are a big part of the distributed model for .NET. Web Services basically provide a programmable entity, such as application logic or data, via the Internet standards such as XML and HTTP. Web Services expose your systems to the Internet to yield highly distributed applications that can interact with

other systems regardless of the operating system or programming language. Web Services meet the challenge of an ultimate heterogeneous environment; it is accessable over the Internet and agnostic regarding the choice of operating system, object model, or programming language.