Better create XML documents in. NET

xml| Create a better XML document in. Net

Author: builder.com

Creating an XML document is not particularly difficult, but it is tedious, especially when you must always create a similar type of document. The task of using code to handle these repetitions can work. But how hard is it or how easy is it to create an XML document using machine-programmed automation? It depends on the method you are using.

Writing markup languages is a tedious task.

The simplistic answer to this question is that creating an XML document is as simple as creating a text document. After all, an XML document is just a text document. But a more realistic answer is that writing markup languages can be a pain in the neck because you have to take care of the loss of quotes, labeling, and attention-case sensitivity. In other words, you have to bear the burden of writing markup languages.

Also, XML documents are essentially hierarchical, which means that you have to write layers in depth--stack based operations. At the time you write, you open the tag, edit the attributes, and increase the child layer, but you need to keep track of the innermost elements that are open. Depending on the syntax of the XML, you must first turn off the innermost elements to comply with the rules that do not overlap.

Writing XML in a DOM way
The XML Document Object Model (XML DOM) allows you to create XML documents using the compositing method. You use a set of manufacturing methods (CreateElement, Createcomment, Createprocessinginstruction, and others) to create instances of node objects and then correlate them to form a tree structure. However, these methods create documents in memory. So how do you keep a new document?

The official API has not provided support for I/O until the second tier of the XML Dom of the consortium. A pair of load and save methods will be part of the approach recommended by the third tier of the official standard XML DOM, and the current third tier is in its final stages. The lack of support for I/O does not necessarily mean that it is problematic for real-world applications, but keep in mind that any Save method you now use for structures like XML DOM is a proprietary extension of the Universal DOM. Microsoft's XML Core Service library (MSXML) provides support for document persistence from the first edition.

The key advantage of XML DOM is that it provides a layer of abstraction that allows you to avoid the limitations of structured XML for your poor programmer. The gist is that you define the structure, and the framework is responsible for the details of the content to the XML document translation. The disadvantage of the XML DOM approach is its memory footprint, which becomes larger as the content of the document increases. The document is completely in memory until it is saved to the storage media. As you can guess, if you're working on a large document, from a performance standpoint, this is not the best approach.


. NET's flow model
Microsoft's. NET Framework provides a more productive, efficient, and even more elegant way for programs to automatically write XML code. On the basis of the XML writer component, this method represents the writing method that corresponds to the flow-based profiling model method that I discussed in the previous article.

The XML writer represents a component that provides a quick and only forward way to output XML data to a stream or file. More importantly, the XML writer guarantees that the XML data that it generates is designed to conform to the rules recommended by the World-view XML 1.0 and namespace.

XML writers and XML DOM objects are different, because the former buffers much less information. The XML writer does not represent a document that is being edited or created in memory. The XML writer is just a simple authoring tool that aggregates the XML text produced by various created elements internally. Unlike the XML DOM, data in the writer's internal cache can be sent to the physical stream at any time-a local disk file, a remote URL, or a stream object.

In a way, you can think of an XML writer component as an abstract API built at the top of the data stream. XML does not have a way to write a string or a set of bytes, and it provides a way to write XML elements and attributes. Let's take a look at an example.

XML Catalog List
Let's say you have to write a class that fills the directory list into XML, and the code in listing a shows how the process should work. This code creates a new XmlTextWriter and starts adding elements. Catalog information can be retrieved using the DirectoryInfo class and its GetDirectories method.

The XmlTextWriter class is the tool you use to create an XML document in a disk file. The null variable passed to the Class builder displays the default encoding structure description (UTF-8) for the document. The formatting property sets the size of the automatic indentation for each line of the document.

WriteStartDocument and writeenddocument are braces for writing a document. The previous method inserts the XML version and encoding information into the standard XML initial structure. The latter method closes all the shelving elements and resets the internal state of the writer object. Between these two calls, you can use other WRITEXXX methods to create specialized XML elements, such as nodes, attributes, and annotations.

ELEMENT nodes are packaged by successive calls to WriteStartElement and WriteEndElement. WriteStartElement corresponds to opening the label; writeendelement corresponds to closing the label. The properties of the currently open element (top of the stack) are set using the WriteAttributeString method. Finally, WriteString inserts the plain text into the body of the element node.

By default, documents are sent to the underlying stream only when the WriteEndDocument method is invoked. However, if you are writing a large document, the Flush method allows you to optimize the memory footprint. Flush can be invoked at any time during the document creation process, emptying the internal cache and updating the underlying stream. The underlying stream is locked before the XML writer completes writing.

The XML writer is a useful help tool, but it is not perfect. It does not compare content with structure descriptions or DTD documents, nor does it correct the error messages that you ignore. For example, if you add the same attribute two times, it will not prompt for an error.

Beyond the Mark
Readers and writers are the basis for each XML I/O operation in the. NET framework. Using an XML reader, you can dissect your document in a more cost-effective way. With XML writers, you can go beyond the mark to a node-oriented level, not just in bytes in contiguous chunks of memory, you can also combine nodes and entities to create an ideal structure description and information set.