The curly braces indicate an expression to be evaluated, rather than output literally. For this template to work though, you would also need to amend the other template to explicit match attributes where the Link attribute was not set to 'Yes'. This is because otherwise the original template would match the case of Link being "Yes" with the same priority as the new template, which is not allowed. This approach has a couple of drawbacks.
There is some repeated code, and also it would be harder to manager if you had other attributes on the Column elements which affected the output of the columns. Here is another version of the XSLT, which makes use of the mode element to repeatedly match the Column attribute, allowing you to potentially output more elements if required.
In this case, the second does not need a check on the Link attribute. Where a template just matches an explicit element name, it will have a lower priority than one that has been qualified with an xpath expression. Therefore the second template will not ever match the case where Link is Yes.
XSLT : Add a namespace declaration to the root element. The author element has two attributes that reference a namespace declared in the article element's start-tag. An XLink-aware application will find those type and href attributes and know what to do with them.
Many simple XML applications never need to declare and use namespaces. If they don't, the XML processor treats all elements and attributes as being in the default namespace. Sample documents and stylesheets are available in this zip file. When this stylesheet's single template rule sees an xdata element in the source tree, it adds two elements to the result tree: a heading element with the string "xdata" as its contents and a text element with the source tree xdata element's contents as its contents.
It turns this. It also adds a carriage return between the result tree's heading and text elements. It does this with an xsl:text element that has a carriage return as its contents. The second of these two text elements has no prefix, so the XSLT processor doesn't treat it as a special XSLT element -- it's just another literal result element. The following stylesheet, which assigns and uses harpo as the prefix for the XSLT namespace, works identically to the one above:. To use these instructions, you declare the namespace mentioned in that processor's documentation and then refer to those instructions using whatever prefix you declared for that namespace.
What if you want your result document to include elements from a specified namespace? Simply declare and use the namespace you need in your stylesheet and the XSLT processor will.
For example, to convert the following HTML document to an XLink document, the result needs an XLink namespace declaration and each of the special XLink attributes need a prefix that references that declaration. XPath defines the local name and namespace URI as properties of the element or attribute node itself and provides functions for accessing those properties.
Specifically, the local-name function returns the local part of the expanded-name, and the namespace-uri function returns the universal part. Table 1. Name tests in XPath 1. These are shown in Table 1. This syntax is only legal in XPath 2. But this will never return a result, because namespace declarations are not exposed as attributes in the XPath data model. Even though namespace declarations use XML 1. Given that knowledge, how many namespace nodes do you think are in the above document?
The answer is: nine. Each of the three elements has three namespace nodes attached to it: a default namespace, the xml namespace, and the namespace bound to the prefix my. This becomes really clear when we realize that an exactly equivalent representation of the above document can be expressed using nine namespace declarations:. This is more like what XPath sees when it looks at the document. It gets past the syntax sugar that allows us to type a namespace declaration once on an ancestor element.
Instead, for each element, XPath sees a namespace node for each in-scope namespace, not unlike what we see in this much more verbose but perfectly valid serialization. Like other XPath node types, each namespace node has an expanded-name and a string-value.
The name of a namespace node is the prefix, and the string-value is the URI that the prefix is bound to. To access namespace nodes in XPath, you use the namespace axis. For example, this expression will select the namespace node attached to the document element that binds the my prefix. The most common use case is creating additional namespaces in the result document.
In addition to the local-name and namespace-uri functions, XPath provides the name function. The name function returns a QName string that represents the expanded-name of the given argument node with respect to the namespace declarations that were in effect on the argument node in the source document. In regard to XPath 2. The easiest way to explain this distinction is by example. Consider the following document, which has two namespace declarations for the same namespace URI:.
In XPath 2. To find an appropriate prefix, the applicable namespace nodes must be queried. In this case, there are two choices, so it could use either one. That said, XPath 1. The difference in XPath 2. Ultimately, this is pretty inconsequential, because it turns out you should avoid using the name function most of the time anyway. This will work as long as your documents use the string atom as the namespace prefix. At that point, what prefix you to choose to use is a mere detail of how you wrote your stylesheet, not an external contract that requires people to use a particular prefix.
The only requirement is that input documents use the correct namespace URI. In most cases, you should avoid using the name function and instead use local-name and namespace-uri to access the two parts of an expanded name.
But I can think of a few cases where using the name function is okay:. Your choices for controlling output namespaces in XSLT 1. Much was left up for the implementer to decide. XSLT 2. This section takes up a good portion of the chapter, and many of the XSLT 2.
But the only way to be truly ready for a real problem when it arises is to have a comprehensive understanding upfront. Most of the time, in XSLT, you will not directly cross paths with namespace nodes. They just get copied along with the element nodes that you copy from the source tree or stylesheet. Similarly, whenever you use a literal result element in your stylesheet, it is treated as an instruction to copy that element from the stylesheet into the result tree.
0コメント