Author: Dino Esposito Transfer: Lion interactive community
This article is assumed to be familiar with Visual Basic .NET
Download this article: xpathandxslt.exe (166KB)
Summary
XPath is a universal query language. With XPath, a set of associated nodes can be identified and processed in XML-based data sources. XPath provides an infrastructure that is an integral part of the XML support in the .NET Framework. The XPath navigation model is even used inside the XSLT handler. In this article, the author examines the implementation details of the XPath Navigator and the XSLT handler, and includes some actual examples, such as asynchronous conversion, sorting node set, and ASP.NET server-side conversion.
One of the main advantages of XML is that it allows you to mark some parts of the text with tags and properties. The reason you have inside the text is that you plan to retrieve it later. So, how to do this? You can use XPath.
Although XPath does not have an XML-based syntax, it is a language defined for some parts of the XML document in a concise, relatively simple way. More importantly, XPath defines a common syntax so that you can retrieve nodes from the XML Document Object Model (DOM) and from XSLT.
In Microsoft® .NET Framework, complete support is provided by the XPath query language by the classes defined in the System.xml.xPath namespace. .NET Framework's implementation of XPath is based on language analysis programs and evaluation engines. The overall architecture of XPath queries is similar to database query. Like the SQL command, you need to prepare XPath expressions and submit them to the runtime engine for evaluation. The query is analyzed and executed for the XML data source. Next, you will retrieve some information that represents the result set of queries. XPath Expressions You can return to the node set (ie, an ordered node collection), Boolean, digital, or string.
In this article, I will explain how XPath is integrated with the XMLDocument class and XSLT in .NET Framework. I will also analyze the XPathnavigator class (.NET Framework uses it to traverse XML documents).
XPath expression
XPath is a specially designed query language for addressing the elements and text of the XML document. The XPath representation is in nature. Any effective expression uses a representation of the hierarchical relationship between nodes to declare node mode. Similar to the file system path, the XPath expression advances from the root (the axis in the XPath term) to a specific node set or value in the source document. However, it is not limited to this similarity to the file system. XPath expressions are always evaluated in the context of nodes. The context node is specified by the application and the starting point of the query. It doesn't differ much from the concept of the current directory.
The context of XPath queries includes, but is not limited to, context nodes and context node sets. The context node set is the entire collection of the nodes processed. Typically, it is a supercoming of the Node Sets that actually returns to the application. The XPath context also contains location and namespace information, variable binding, and a standard library available for application extensions. Any implementation of the XPath analysis program provides a library for evaluating the expression. The extension function is defined in a vendor's XPath implementation, but can also be provided by dedicated and XPATH-based programming APIs (eg, XSL conversion, and XPointer). XPath expressions are usually returned to the node set, but the Boolean, strings, numbers, and other types are also supported.
The most commonly used XPath expression type is the location path. The location path is a very similar expression that looks similar to the file system path, which can either an absolute path or relative to the context node. The absolute position path begins with a forward slash. As shown in Figure 1, the fully qualified position path consists of three parts: axis, node testing, and one or more predicates. The axis information defines the initial context node set of the expression, and the node test is a series of node names identifying the path in the node. The predicate is a logical expression that defines the conditions for filtering the current node set. Figure 1 location path
The XPath expression can contain any number of predicates. If no predicate is specified, all child nodes of the context node are returned in the query. Otherwise, using a simple and operator will be logically connected in series with various predicate settings. Note that predicates are processed in the order they appear so as to set up a node that generates a predicate generated by the next predicate.
When processed, the XPath expression is submitted in a sub-expression named position step, and each expression is calculated separately. The XPath handler is transmitted in an iterative manner and the sub-expression and context node set generated in the previous step. It returns a set of nodes that may shrink to use as the input parameters of the next sub-expression. In this process, context nodes, positions, and size may vary, and variables and function references and namespace declaration remain unchanged. Each position step is actually a location path, so it can be represented in an abbreviated form or a fully qualified form as needed. The position step is separated by a forward slash.
In the .NET Framework, the XMLNode class can be disclosed in the XMLDocument class, or XPath Expressions are used via the XPathnavigator class.
XPath Navigator
In .NET Framework, the XMLDocument class represents the standard XML DOM (DOM level 2 standard) approved by W3C. Several search methods are implemented on each child node arriving from XMLDocument. The XMLNode class provides SelectNodes and Selectsinglenode methods, which search nodes in the document using XPath expressions. These methods are almost identical to a similar name based on COM-based MSXML libraries. SelectNodes returns a series of objects, while selectsingLenode only returns the first object that matches the search criteria. The following is a way to use SelectNodes:
DIM DOC AS XMLDocument = new xmldocument () doc.load (filename) Dim nodes as xmlnodelistnodes = doc.selectnodes (querystring)
The SelectSinglenode method is different from SelectNodes that it returns a single XMLNode object. Later, I will discuss these methods in detail.
XMLDocument support for XPath expressions has two goals. It makes the conversion from the MSXML COM code to the .NET Framework, and provides a built-in mechanism for searching nodes in the memory map XML document. However, XMLDocument query API is a simple high-level package. The core of the XPath expression is used to process the XPathNavigator class. Net Framework API is generated around the XPathnavigator class. The Navigator is an XPath handler that works on the XML data store of any public ixpathnavigable interface. The Navigator is rendered by the interface defined in the XPathnavigator class, which uses the SELECT method to analyze and perform expressions. Unlike the XMLDocument method, the navigator accepts the expression provided in plain text and provides expressions by pre-compiling objects. You can access the XPathnavigator object from the XMLDocument class or the XPathDocument class. Figure 2 illustrates two ways to access the XPath function in the .NET Framework. Figure 2 Access XPath function
The following code snippet shows how to create XPathnavigator according to XML documents and how to perform XPath queries:
Dim doc As XPathDocumentDim nav As XPathNavigatorDim iterator As XPathNodeIteratordoc = New XPathDocument (fileName) nav = doc.CreateNavigator () iterator = nav.Select (queryString) While iterator.MoveNext () 'nav points to the node subtreeEnd While
The navigator returns an XPath iterator object. The iterator is just a dedicated enumerator object used to move in the returned node. I will discuss iterators later.
Document, Navigator and Reader
Processing an XML file involves processing documents presented in accordance with SAX or XMLDocument specification before .NET Framework appears.
The XPath handler (which is an engine analysis and execution XPath query) is generated inside the Xpathnavigator class. As shown in Figure 2, XPath computing is always entrusted to the navigator, regardless of the high-level caller API. The navigator operates on a specific data store (usually an instance of the XPathDocument class). As long as the data store class implements the IXPathnavigable interface as shown below, other data stores can also be used:
Public interface ixpathnavigable {xpathnavigator createnavigator ();
In addition to the XpathDocument class, the samples of the data store also include XMLDocument and XMLDATADOCUMENT.
The data store is responsible for providing a navigator to explore the XML content in memory. The XPathnavigator implementation is always specific to the storage area and is generated by inheriting from the XPathnavigator abstraction. Although you are actually writing a navigator through the common reference type of XPathnavigator, each data storage area has its own navigator objects. They are unprecedented classes internally, which cannot be accessed in programming and is usually implemented in considerable ways. Figure 3 lists the true navigator classes used by the three XPath data storage areas defined in the .NET Framework. A document-specific navigator utilizes the internal layout of the document class to provide navigation API.
The XpathDocument class provides highly optimized, read-only memory storage area for XML documents. This class is designed to implement the XPath data model, it does not provide any identifier for the node. It just creates a foundation node reference tree so that the navigator can operate quickly and effectively. The internal architecture of the XPathDocument class looks like a node referenced list. The node is managed by a small class represents a small subset representing an XMLNode class (see Figure 2). Compared to XPathDocument, the XMLDocument class provides read and write access to the nodes of the underlying XML document. In addition, each node can also be accessed separately.
The XMLDocument class also provides the ability to create a navigator object, as shown below:
DIM DOC AS XMLDocument = new xmldocument () Doc.Load (filename) DIM NAV AS XPATHNAVIGATOR = Doc.createnavigator ()
The XMLDocument's navigator class implements the iHasxmlNode interface. This interface defines a method, namely getNode:
Public interface ihasxmlnode {xmlnode getnode ();
Using this method, the caller can access and ask the currently selected node in XMLDocument based on the location of XPathnavigator. This feature cannot be implemented for XpathDocument-based navigator, which is only known to disclose internal structures through the XMLNode class like the XMLDOCUMENT class. This is the design makes it. XpathDocument minimizes memory footprints and does not provide node identity.
Because the getNode method is implemented on the XPathnavigator class on XMLDocument, the caller can use it by type conversion, as shown in the following code segment:
Dim doc As XmlDocument = New XmlDocument () doc.Load (fileName) Dim nav As XPathNavigator = doc.CreateNavigator () Dim i As XPathNodeIterator = nav.Select (query) Dim node As XmlNode = CType (i.Current, IHasXmlNode). GetNode ()
At this point, the caller has obtained full access to the node and can be read and updated any.
Finally, the XMLDATADOCUMENT class is an extension of XMLDocument, and its goal is to allow the relationship between the XML manipulation. This is a concise example, which illustrates the fact that the .NET Framework navigation API can be applied to XML-based data and data similar to XML (data to XML, but not XML).
If you look at the MSDN® document of the XPath Navigator, you will see the Navigator read data from XML-based data storage regions in a way that is similar to the cursor (forward and back), and only read only the basic data. access. In addition, it maintains information about the current node and uses a variety of moving methods to advance the internal pointer. When the navigator is positioned at a given node, all of its properties will reflect the value of the node. Of course, this is similar to the XML reader (I discussed it in an article in MSDN Magazine's May 2003. What is the difference between the navigation and readers?
Navigator and readers are different. The reader is similar to the dragon tape cursor, which provides basic read-only, only moving. The navigator is also read-only, but they offer a wide range of mobile methods (including forward and backward options). The navigator also provides multiple selection methods to fine-tune the search. The reader is a lower level tool that can be used to read XML-based or similar to XML data, and the data structure in memory. The XML reader can be used to generate data structures in memory dependent on the navigator. Query node
Suppose you need to implement XPath queries in applications based on .NET Framework. Is the XPath navigator should be used, or it is best to adhere to the Node interface using XMLDocument? XMLNode's SelectNodes method uses a navigator object to retrieve a list of matching nodes. Subsequently, use the return value of the Select method of the navigator to initialize an internal node list object that is type XPathNodeList (which defines in the System.xml.xPath namespace). As you may have guessed, this class is inherited from the published XMLNodeList class. In addition, different from SelectNodes is that the navigator can completely utilize the compiled expression.
The SelectNodes method always accepts XPath expressions in plain text. The string is then passed to the navigator one by words. Only in one case, the basic navigator receives the compiled expression. If you use the SelectNodes method for processing namespace information, the XPath expression is first compiled, and then it passes it to the handler. The prototype of the overload method is as follows:
Function selectnodes (_ xpatHexpr As String, _ nsm as xmlnamespacemanager) _AS XMLNodelist
When you frequently use this expression frequently in the session, the advantages of compiled expressions become very obvious, and they have namespace recognition. The XMLNamespaceManager class allows the user to specify the prefix of the namespace to be bound.
The Selectsinglenode method is the special case of SelectNodes, which only returns the first element of the returned node set. Unfortunately, until now, SELECTSINGLENODE is not particularly effective. If you only need to find the first match node, call SelectsingLenode or SelectNodes almost identical. Moreover, if you need to do everything possible to improve performance, you can use SelectNodes better. The pseudo code below illustrates the current implementation of Selectsinglenode:
Function selectsinglenode (XPATHEXPR AS STRING) AS XMLNode Dim Nodes as XMLNodeList = SelectNodes (XPATHEXPR) Return Nodes (0) End Function
This method calls SelectNodes inside and returns the first matching node. However, please note that XMLNodeList is dynamically generated - only the next node is searched only when the request is received.
A better way to query a single node is to pass a more precise XPath expression that returns a single node to SelectNodes. Its thinking is to avoid using the general wildcard expressions as shown below:
NorthwindemPloyees / Employee
You should place a stronger filter on the XPath expression so that it returns the correct node subset of size. To get only the first node, add an extra predicate to stop the query after finding the first match:
NorthwindemPloyees / Employee [position () = 1]
This is usually XPath best practices and is not particularly due to .NET Framework implementation. This method can be refined and summarized in order to adjust the size of the node set as needed. The following query string shows how to get the N-match node:
NorthwindemPloyees / Employee [position () When you need to perform actions to perform an operation with a selected node identified by a form, I suggest you use XMLNode's SelectNodes instead of XPathNavigator instances to perform XPath queries. If you need to further manage the node as an instance of the XMLNode class, you can simplify the code using SelectNodes. Programming Xpathnavigator Let's learn about the knowledge about the programming interface of XPathnavigator. Usually, regardless of which application level API is used, the step sequence required to perform XPath queries for XML data sources is approximately the same: 1. Get a reference to the document class that supports XPath (for example, an instance of the XPathDocument or XMLDocument class). 2. Create a navigator object for the specified data store. 3. If you plan to reuse XPath expressions after you plan, it is also possible to prepare it. 4. Call the Select method of the navigator to take action. The programming interface of the navigator object is defined in the XPathnavigator abstraction class. Although you usually use a navigator object to perform XPath queries, it is not worth it if you let the XPathnavigator class represent more common components. The navigator is a general interface that acts as a detector similar to the cursor to detect any data store that will be disclosed as XML. Despite the functionality similar to the XML reader, for simple reading operations, the navigator does not have the former quickly and valid because it is a tree navigator and is specifically used to search. If you only need to read an XML document, use an XML reader; if you need to perform a query, use the navigator. Keep in mind that the navigator is now working on a fully stored data source. Functionally, the XPathnavigator class is not very different from the pseudo categories that combine all the methods required to navigate document content. A large difference is that Xpathnavigator is a unique component that is completely separated from the document class. In other words, XPathnavigator represents an XML view of a data store that has been mapped to the XML data model. Figure 4 enumerates the available properties on the XPathnavigator class. Like an XML reader and an XMLDocument class, XPathnavigator uses a name table to store repeat strings more effectively. This property set looks like a subset of the properties of the current node in the XMLTextReader class. It is worth repeating that the SELECT method of XPathnavigator returns an iterator object that is referenced later as a navigator (XPathnavigator class). To access and process node information, you can only use the properties of the navigator. The attributes in Figure 4 are read-only, and more importantly, they are not mapped to an instance of the XMLNode class. If you need to manipulate the node as an XMLNode object (for example, for application changes) to ensure that XMLDocument is used as the data storage area class, then convert the current element of the iterator to iHasxmlNode. From the reference type, iHasxmlNode calls the getNode method, which returns the XMLNode instance of the underlying node. In all other cases, access to nodes is read-only. Navigator objects provide a wealth of ways, and I divide them into three major groups based on these methods: choice, movement, and miscellaneous. The following code snippet selects the descendants of the node. The code used to get a ancestor is almost identical: DIM DOC AS XPATHDocument = new xpathdocument (filename) Dim Nav As XPathnavigator = Doc.createnavigator () Nav.selectDescendants (Nodename, nsuri, selfincluded) SelectDescendants uses the local name of the node and selects descendants. NSURI variable indicates the namespace URI of the descendant node (if present). The SelfiNCluded Boolean variable is a flag indicating whether the context node should be included in the node. Figure 5 contains a list of mobile methods for XPathnavigator. You can restroom in accordance with the namespace, jumping in either direction - forward or rear (from the coming to the same generation). As you may have noticed, there are three sets of mobile methods, which apply to elements, attributes, and namespace nodes, respectively. Only Moveto and MoveToroot methods can be called on any node (regardless of the type). In addition, the attributes and namespaces have methods for returning their values: GetAttribute and GetNamespace. When selected, the NAME attribute of the navigator returns a namespace prefix. The value attribute returns the URI. Figure 6 is grouped for all other methods defined on the XPathnavigator class. Several methods are related to the XPath expression. The XPath expression is a string representing a location path (although it is not just a normal command string). It has a surrounding context from the XPATHEXPRESSION package. The context of the expression includes returning type and namespace information. The XPATHEXPRESSION class is not created publicly. To get a new instance, you must get an XPath string expression and compile it to the XPATHEXPISSION object. The following code snippet shows how to compile the expression and display its expected return type: DIM EXPR AS XPATHEXPRESSION = Nav.Compile (XPATHEXPR) Console.Writeline (expr.returntype.tostring ()) Nav.select (expr) Compiled XPath expressions can be consumed by SELECT, EVALUATE, and MATCHES methods. The term "compilation" here does not mean the XPath expression becomes an executable expression. Simply, compilation operations must be treated as a process of generating objects by collecting various information clips. Expressions can return various types of values other than node sets. In this case, the expression is calculated using the Evaluate method, and then converts the returned general object to a specific type. Select is a more special way because it assumes that the return type is a node set and inserts these nodes into iteters. Sort node set An interesting extension built in the XPATHEXPRESSION class is to be sorted before passing the node set back to the call. To add a sort algorithm, you need to call the AddSort method on the XPATHEXPRESSION object. ADDSort has two forms: Sub Addsort (Expr As Object, Comparer As IComparer) Sub Addsort (Expr As Object, Order As Xmlsortorder, _ CaseRder As XmlcaseOrder, Lang As String, _ Datatype As XmlDataType) The EXPR parameter represents the sorting key. It can be a string representing the node name, or another XPATHEXPRESSION object capable of calculating a node name. In the first overload, the Comparer parameter references an instance of the class that implements the class of the IComparer interface. This interface provides a Compare method, which is actually used to compare a pair of values. Use this overload if you need to specify a custom algorithm in order to sort the nodes. The second overload is always executed in value or text comparison based on the value of the DataType parameter. In addition, you can specify sort order (ascending or descending), even specify the ordering order of uppercase and lowercase letters (or you can completely ignore uppercase by using the value XmlcaseOrder.none). Finally, the LANG parameter specifies which language to use. Language names should also specify locale. For example, to indicate American English, it is best to use "US-en" rather than simply use "en". Let us discuss the IComparer interface more deeply. In order to sort the object array, .NET Framework provides several predefined comparator classes, including Comparer and CaseInsitiveComparer. Comparator class compares objects (usually strings) relative to case. CaseinSensitiveComparer completes the same job, but ignores cases. To use these two classes in your code, be sure to import System.Collections namespace. The Comparer class does not have a public constructor, but provides a single instance through the DEFAULT static properties. E.g: EXPR.ADDSORT ("Lastname", Comparer.default); You can also create your own comparator class if needed. The following code shows a fairly normal Visual Basic® .NET implementation: Class MyOwnStringComparer Implements IComparer Public Function Compare (x As Object, y As Object) _ As Integer Implements IComparer.Compare Dim strX As String = CType (x, String) Dim strY As String = CType (y, String) Return String.Compare ( STRX, STRY) End Subend Class If the two strings are equal, the Compare method should return 0; if X is in Y, the method returns a value greater than zero; if Y is in X, it returns a negative value. This class can also define in the body of the application and do not require separate assemblies. The following code associates a custom comparator with an XPath expression: Dim Comp as myownstringcomparer = new myownstringcomparer () expr.addsort ("lastname", comp) Figure 7 shows an application of the technology. After creating a navigator for an XML document, the sample console application recompores the expression you want to use. Assuming data sources have the following architecture: Sort by a single node is easy - just pass the node name to the AddSort method. Sort by multiple fields is more complicated. The idea is to indicate a list of nodes separated by commas. However, the parameter string must be an XPath expression that can calculate the list of node names separated by comma. If you simply specify the sorting keyword as a "title, lastname", you will get a runtime error because the XPath handler is incorrectly regarded as the actual node name. Really needed that the XPath handler can convert it to the desired title at runtime, as shown below: DIM Sortkey as string = "Concat (Concat (Title, ','), Lastname" Concat Keyword Identifies one of the predefined helper functions provided by the XPath implementation. In Figure 7, you can also understand how to effectively use iterators. One point to note when using the XPath iterator is that the code traverses all nodes in the node set one by one. You will have to go deep into the subtree of each node. To do this, first clone the navigator to avoid the main navigator, thus damaging the outermost loop: Dim iterator As XPathNodeIterator = nav.Select (expr) While iterator.MoveNext () Dim nav2 As XPathNavigator = iterator.Current.Clone () nav2.MoveToFirstChild () ••• nav2.MoveToNext () ••• End While The Current property on the iterator returns the current node in the node set. It calculates an instance of the XPathnavigator class and can be cloned using Clone methods. XSL overview in .NET XML conversion is a user-defined algorithm that the user-defined, trying to express a given document with additional (equivalent) syntax. The conversion process contains a style sheet-based structure to present a source document. The style sheet is a declarative user-defined document that contains a rule set for converting a document to another document. XSL refers to a meta-language designed to represent a style sheet for an XML document. The XSL file was originally imagined as an XML counter corresponding to the HTML Cascade Style Table (CSS). In view of this, XSL is designed to be scalable, user-definable tool, which can be displayed with HTML to display. The growing complexity of the style sheet and the emergence of XML architecture have led to the generation of XSLT. At present, XSL is just a general term for many derived technology, which can better describe and implement the original idea of XML document style. The various components contained in XSL are actual software entities used in the code: XSLT, XPath, and XSL formatted objects (XSLFO). The XSLT program is a general conversion rule set that can be any text-based language, including HTML, RTF, and more. As mentioned earlier, XPath is a query language, and the XSLT program can use it to select a specific part of the source XML document. The results of the XPath expression are then analyzed and elaborated by the XSLT handler. Typically, the XSLT handler sequentially processes the source document, but if you require access to a specific node group, it will pass the source document to XPath. In .NET Framework, the core class of XSLT is XslTransform. This class is located in the System.xml.xsl namespace and implements the XSLT handler. Two steps can be taken to use this class: first load the style sheet in the handler and then apply to any more source document as needed. The xsltransform class only supports the XSLT 1.0 specification. The C # code in Figure 8 implements a command line XSLT converter. It uses three command line parameters (XML sources, XSLT style sheets, and output files) to set the handler and save the conversion result into the output file. XSLTransform class The XSLTransform class provides two ways specific to its activities - LOAD and Transform. This class only ensures a thread security mode during the conversion operation. In other words, although the instance of such a class can be shared by multiple threads, only the Transform method can be safely called from multiple threads. The LOAD method is not a thread safe. The Transform method reads the shared status and can operate in multiple threads. Figure 9 shows a portion of the internal architecture of the class. After loading the style sheet, the XSLT handler needs to modify its status to reflect the loaded document. This operation does not occur in an atomic manner in a virtual boundary created by the lock statement. Therefore, concurrently running threads can access the same XSLT handler instance to destroy data consistency. The loading operation is a thread sensitive because it changes the global state of the object. Figure 9 XSL Transform class In the version 1.0 of .NET Framework, the XSLTransform class adds a link request permission set. The link request specifies which permissions must have the code to run the code. The calling party performs inspections during immediate compilation: [PermissionSet (securityAction.LinkDemand, Name = "fulltrust")] public Sealed class xsltransform {••} The permissions set at the XSLTransform class are represented by the name and pointing one of the built-in permission sets - FullTrust. What does this mean for users? Only a caller with all local resources has a completely trusted access authority (this check involves direct calls, instead of the caller's caller) can only be safely called to the XSLT handler. For example, if you share a XSL handler over a web, you will trigger a safe exception. In the .NET Framework version 1.1, the permission set has been removed. In the overall behavior of the .NET Framework XSLT handler, three phases can be explicitly identified: the loading, internal state settings, and conversion of the style table document. The first two phases occur in the context of the LOAD method. Of course, the Transform method cannot be called until the previous LOAD call is successfully terminated. The LOAD method always works synchronously so that when it returns, you can make sure the load step has been actually completed. You will not receive any return values that indicate fails or success. However, whenever there is any error in the LOAD method, some exceptions will be triggered. In particular, if you point to a lost style sheet, you will get an exception of the FilenotFoundException type; if the XSLT script contains certain errors, the more general exception of the XSLTCompileException type will be obtained. XSLTCompileException exception provides a line location and number that occurred in the style sheet. You can load the input style sheet from four different source: URL, XML reader, XpathDocument, and XPathnavigator. No matter which source, the first operation of the LOAD method is to represent the source as an XPathnavigator object. The style sheet must be compiled, and, considering the architecture of the compiler, the navigator is a very effective object. "Compilation" is such a process, which is simply extracted from the original style table and stores it in a convenient data structure for further use. The entire set of these data structures is called the status of the XSLT handler. Figure 10 shows the flow of the LOAD method. Figure 10 LOAD method process The style sheet compiler fills three internal data structures with data read from the source. As an object that is referenced by the compiled style table object represents a index of the style table content. Other two objects are a table containing the compiling version of the XPath query to be executed and a table you need to operate in various templates. The Transform method uses at least two explicit parameters - source XML documents and output streams, plus several implicit parameters. Of course, the compiled style table object is one of the implicit input parameters. The second implicit parameter is the content of XSLTransform's XMLRESOLVER attribute (which is specifically used to parse external resources). The Transform method also uses the third explicit parameter-class xsltargumentList. This parameter contains the namespace defined parameters used as the input of the conversion process. The XML source document is standardized to XPathnavigator and passed to the XSLT handler. Interestingly, the Transform method has two types of overload. Some of these overloads work as the VOID method and just write the specified stream. Other overloads work as a function and explicitly return an XML reader object. As I will discuss later, this feature provides a very interesting opportunity: achieve asynchronous XSLT conversion. In Figure 11, it can be seen that the execution stream of the Transform method can be seen. Figure 11 TRANSFORM method The Transform method also allows you to deliver parameters to the style sheet using an instance of the XslTargumentList class. When passing parameters to the XSLT script in this way, it will not be specified which template call will actually use these parameters. You just pass the parameters to the XSLT handler in a global way. The internal modules responsible for handling the template will then read and import these parameters as needed: xsltargumentlist args = new xsltargumentlist (); args.addparam ("MaxNumofrows", ", 7); addparam method creates a new entry in the parameter list . This method requires three parameters: parameter name, named space URI (if the name is defined by named space prefix) and an object representing the actual value. This parameter value must correspond to the effective XPath type: string, Boolean, digital, node segment, and node set. The figures correspond to the double precision type, and the node clips and node sets are equivalent to the XPathnavigators and the XPath node iterator. The parameters and extended objects XSLTargumentList are not a collection-based class. It is not derived from the collection class, nor does it implement any typical list interfaces (such as ILIST or ICOLLECTION). The XSLTargumentList class is generated around several hash tables - a XSLT parameter, one for collecting extended objects. Extended objects are an active instance of the .NET object, which can be passed to the style sheet as a parameter. For example, the XSLT script can be extended in a variety of ways to obtain the functions provided by the embedded XPath library. The XSLTransform class supports Now, you need to use the prefix "Dino" to qualify any call to any function defined in the Asynchronous method has several XSLT Transform XML reader is able to return overloaded: XmlReader Transform (XPathNavigator input, XsltArgumentList args); XmlReader Transform (IXPathNavigable input, XsltArgumentList args); these overloaded signatures and other heavy-duty behavior slightly different. First, the input document must be xpathnavigator or xpathdocument. More importantly, these methods do not accept any parameters representing the output stream. In fact, the output of the conversion process is not written in the stream, but is created in the stream and returned to the user via the XML reader. The entire XSLT process in .NET Framework works by creating an intermediate data structure (input navigator), in this data structure, the content of the style sheet is used as the base basis. Any The conversion element can be provided by pointing the URL of the XSL file or by an instance of the XslTransform class (Transform property). You can also use the TransformargumentList property to indicate the parameters if needed. The component provides a great solution to the HTTPBrowserCapabilities class, providing a great solution for common needs (data-driven web pages, and browser output). Note that only the format specification XML data can be used with the td> xsl: template> If you add quotation numbers before and after the parameter, they will be considered a literal value. To ensure that the managed function receives the node value, use the same expression as the expression of the Select property for the