Exsl Win V9 64bit 14
Harold Yengo
because the prefix "exslt" has not been declared. Perhaps you meant "exsl". At present, "exsl" is not declared as an extension namespace, therefore "exsl:document" is a simple literal result element rather than an instruction.
Hi I'm trying to do XSLT transformation, In this process I'm using predefined function "exsl:node-set($MyVar)" this function is working fine in oxygen xml editor but Altova XMLspy throws an error "XPST0017: The function call 'exsl:node-set' does not match the name of a function in the static context". And WSO2 XSLT transformation also unable to do transformation. How can i solve this problem ?
The exsl:document element is used to create multiple result documents. As well as the main result document, there can be subsidiary result documents. Each subsidiary result document is created using an exsl:document element. The content of the exsl:document element is a template; this is instantiated to create a sequence of nodes; a root node is created with this sequence of nodes as its children; the tree with this root node represents the subsidiary result document. The href attribute specifies where the subsidiary document should be stored; it must be an absolute or relative URI; it must not have a fragment identifier. For example, the following would create a main result document specifying an HTML frameset with two frames, together with two subsidiary documents, one for the contents of each frame:
The attributes on xsl:output elements affect only the main result document. The output of a subsidiary result document is controlled by the attributes on the exsl:document element that was used to create that subsidiary result document. With the exception of the href attribute which is allowed only on exsl:document, the attributes on exsl:document are applied to a subsidiary result document in the same way that the attributes on xsl:output are applied to the main result document. In particular, the method attribute on an exsl:document element is defaulted based on the content of the subsidiary document created by that exsl:document element, not based on the content of the main result document.
Normally, exsl:document can be understood as directly creating an additional result document. However, when exsl:document is used within xsl:variable or xsl:param elements, the following more sophisticated conceptual model is needed.
One category contains the documents that the XSLT processor constructs by instantiating templates; these are the main result document, subsidiary documents created by exsl:document, and documents created by a variable-binding element with content.
The other category contains the documents constructed by parsing or other processes external to the XSLT processor; these are the main source document and documents returned by the document function.
With each document in the former category, an XSLT processor associates a possibly empty set of subsidiary documents. The relationship between a document and its associated subsidiary documents thus organizes documents in this category into one or more unordered trees, where the associated subsidiary documents of a document are considered the children of that document. The main result document is the root of one such tree; the documents created by variable-binding elements with content are the roots of the other trees. Each subsidiary document created by an exsl:document element has a parent within this tree of documents.
During the processing of a stylesheet, there is a current result document; initially this is the main result document; the current result document is changed by the exsl:document element and by variable-binding elements with content. When an exsl:document element is instantiated, the content is instantiated with the subsidiary document being created by that exsl:document element as the current result document. When a variable-binding element with content is instantiated, the content is instantiated with the document being created (that is, the document whose root node is the sole member of the node-set that will be the value of the variable defined by that element) as the current result document. A document created by the instantiation of an exsl:document is not automatically output; instead, it is added to the set of subsidiary documents associated with the current result document.
When a root node is copied with xsl:copy or xsl:copy-of, the subsidiary documents associated with the document of which it is the root node are copied and added to the set of subsidiary documents associated with the current result document. Copying a subsidiary document copies its subsidiary documents recursively.
Output conceptually follows the construction of the main result document and any subsidiary documents. The XSLT processor outputs the main result document and its associated subsidiary documents; when the XSLT processor outputs a subsidiary document it also recursively outputs its associated subsidiary documents. Apart from this, no other subsidiary documents are output. A subsidiary document associated with the document created by a variable-binding element with content is not output; only copies created by the copying of the root node of that document are ever output.
For each document that is output, there is an absolute URI that can, in the appropriate circumstances, be used to access that document. Call this the output URI of the document. The output URI of the main result document is system-dependent, typically specified when the XSLT processor is invoked. When the href attribute of a subsidiary document is an absolute URI, then that absolute URI serves as the output URI. When the href attribute of a subsidiary document is a relative URI, the relative URI is resolved into an absolute URI only if and when the subsidiary document is output. The output URI of the document with which the subsidiary document is associated (ie the output URI of its parent in the tree of documents) is used as the base URI. The resulting absolute URI is used as the output URI of the subsidiary document.
It is an error if the set of documents to be output as the result of a single XSLT transformation (that is, the main result document and its subsidiary documents recursively) contain two documents with the same output URI.
The XSLT language is capable of achieving many tasks, but some surprisingly trivial requirements, such as calculating the total amount of an invoice, cannot be expressed in a straightforward way. This article describes how you can get round this by using a very powerful extension function in your stylesheets: the node-set() function.
The variable $books now contains a set of nodes. Thus you can use this variable in other XPath expressions without any limitations. For example, you can use the expression $books/title to get the titles of all books from the catalog.
So far, so good, but XSLT added a new data type called "result tree fragment" into XPath. You can imagine a result tree fragment (RTF) as a fragment or a chunk of XML code. You can assign a result tree fragment to a variable directly, or result tree fragment can arise from applying templates or other XSLT instructions. The following code assigns a simple fragment of XML to the variable $author.
Now let's say we want to extract the e-mail address from the $author variable. The most obvious way is to use an expression such as $author/email. But this will fail, as you can't apply XPath navigation to a variable of the type "result tree fragment."
If we want to get around this limitation, we can use an extension function which is able to convert a result tree fragment back to a node-set. This function is not a part of the XSLT or XPath standards; thus, stylesheets which use it will not be as portable as ones which don't. However, the advantages of node-set() usually outweigh portability issues.
Extension functions always reside in a separate namespace. In order to use them we must declare this namespace as an extension namespace in our stylesheet. The namespace in which the node-set() function is implemented is different for each processor, but fortunately many processors also support EXSLT, so we can use the following declarations at the start of our stylesheet.
The expression exsl:node-set($author) converts the result tree fragment to a node-set; we can take it as a start for further XPath navigation. If our processor is not EXSLT-aware we must change the namespace according to Table 1.
Let's suppose that we want to create a stylesheet that is able to render a simple XML invoice into nice HTML for further browsing and printing. For the sake of simplicity our invoice contains just items, each item has a description, ordered quantity and unit price.
We don't want to be responsible for putting a damper on the party, so we will write a stylesheet for turning this XML into HTML. However, there is one complication: the rendered invoice should certainly contain the total amount. This might look like a simple task, but it will quickly become apparent that XPath and XSLT will fail here. XPath provides us with the sum() function, but it is only possible to sum values of nodes, and in our example we want to calculate a sum of subtotals (qty * unitPrice), which are not present in the source XML and thus are not accessible to XPath's sum(). The only pure XSLT 1.0 solution is to use recursive processing, which leads to code that is not very clear and easy to understand. (A pure XSLT solution is presented in invoice-noext.xsl stylesheet in the ZIP archive with all examples.)
Multipass processing is another situation in which the node-set() function is essential. In some situations it is hard to do the transformation in a single step; some post-processing on the result is needed. If we want to do this during a single transformation without the need for storing a temporary result, and without the need for repeated invocation of the XSLT processor, we must capture the result of the first transformation in a variable as a result tree fragment (RTF), convert the RTF to a node-set, and feed this node-set to templates which are responsible for post-processing.
b1e95dc632