8,909
社区成员
发帖
与我相关
我的任务
分享/ 和 有和区别
<xsl:template match="/">
...
</xsl:template>
和
<xsl:template match="root">
...
</xsl:template>
有何区别，其中root为xml document的root element
如果没区别
那
<xsl:stylesheet version="1.0"
xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
<xsl:output method="xml" indent="yes" omit-xml-declaration="yes"/>
<xsl:template match="/">
<xsl:for-each select="COLLECTION/BOOK">
<xsl:apply-templates select="TITLE"/>
<xsl:apply-templates select="AUTHOR"/>
<xsl:apply-templates select="PUBLISHER"/>
<BR/> <!-- add this -->
</xsl:for-each>
</xsl:template>
<xsl:template match="TITLE">
Title - <xsl:value-of select="."/><BR/>
</xsl:template>
<xsl:template match="AUTHOR">
Author - <xsl:value-of select="."/><BR/>
</xsl:template>
<xsl:template match="PUBLISHER">
Publisher - <xsl:value-of select="."/><BR/><!-- removed second <BR/> -->
</xsl:template>
</xsl:stylesheet>
为何可以正确用在
<?xml version="1.0"?>
<?xml-stylesheet type="text/xsl" href="xslinclude.xsl"?>
<COLLECTION>
<BOOK>
<TITLE>Cosmos</TITLE>
<AUTHOR>Carl Sagan</AUTHOR>
<PUBLISHER>Ballantine Books</PUBLISHER>
</BOOK>
<BOOK>
<TITLE>Catwings</TITLE>
<AUTHOR>Ursula K. Le Guin</AUTHOR>
<PUBLISHER>Scholastic</PUBLISHER>
</BOOK>
<BOOK>
<TITLE>Home Town</TITLE>
<AUTHOR>Tracy Kidder</AUTHOR>
<PUBLISHER>Random House</PUBLISHER>
</BOOK>
</COLLECTION>
<xsl:template match="/">
<xsl:for-each select="COLLECTION/BOOK">
不是说明COLLECTION是/的child element吗
...
</xsl:template>
和
<xsl:template match="root">
...
</xsl:template>
有何区别，其中root为xml document的root element
如果没区别
那
<xsl:stylesheet version="1.0"
xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
<xsl:output method="xml" indent="yes" omit-xml-declaration="yes"/>
<xsl:template match="/">
<xsl:for-each select="COLLECTION/BOOK">
<xsl:apply-templates select="TITLE"/>
<xsl:apply-templates select="AUTHOR"/>
<xsl:apply-templates select="PUBLISHER"/>
<BR/> <!-- add this -->
</xsl:for-each>
</xsl:template>
<xsl:template match="TITLE">
Title - <xsl:value-of select="."/><BR/>
</xsl:template>
<xsl:template match="AUTHOR">
Author - <xsl:value-of select="."/><BR/>
</xsl:template>
<xsl:template match="PUBLISHER">
Publisher - <xsl:value-of select="."/><BR/><!-- removed second <BR/> -->
</xsl:template>
</xsl:stylesheet>
为何可以正确用在
<?xml version="1.0"?>
<?xml-stylesheet type="text/xsl" href="xslinclude.xsl"?>
<COLLECTION>
<BOOK>
<TITLE>Cosmos</TITLE>
<AUTHOR>Carl Sagan</AUTHOR>
<PUBLISHER>Ballantine Books</PUBLISHER>
</BOOK>
<BOOK>
<TITLE>Catwings</TITLE>
<AUTHOR>Ursula K. Le Guin</AUTHOR>
<PUBLISHER>Scholastic</PUBLISHER>
</BOOK>
<BOOK>
<TITLE>Home Town</TITLE>
<AUTHOR>Tracy Kidder</AUTHOR>
<PUBLISHER>Random House</PUBLISHER>
</BOOK>
</COLLECTION>
<xsl:template match="/">
<xsl:for-each select="COLLECTION/BOOK">
不是说明COLLECTION是/的child element吗
...全文
请发表友善的回复…
发表回复
aviatorbai 2003-09-01
- 打赏
- 举报
见下面：
－－－－－－－－－－－－－－－－－－－－－
格式正规的XML文档的定义形式是一个简单的层次树，每个文档都有一个而且只有一个根节点，它被称作文档实体(document entity)或文档根(document root)。这个节点可能包含PI/和/或注释，而且总是包含子元素树，它们的根被称作文档元素(document element)。这个元素是这个树中其它的所有元素的父元素，而且它可能不包含在其它任何元素当中。由于文档根和文档元素并不是一回事，所有最好不要把“文档元素”看作是“根元素”。而文档根才是所有XML的根。选自 <<XML高级编程>>
－－－－－－－－－－－－－－－－－－－－－
其实就是：document root 和document element的区别了。
－－－－－－－－－－－－－－－－－－－－－
格式正规的XML文档的定义形式是一个简单的层次树，每个文档都有一个而且只有一个根节点，它被称作文档实体(document entity)或文档根(document root)。这个节点可能包含PI/和/或注释，而且总是包含子元素树，它们的根被称作文档元素(document element)。这个元素是这个树中其它的所有元素的父元素，而且它可能不包含在其它任何元素当中。由于文档根和文档元素并不是一回事，所有最好不要把“文档元素”看作是“根元素”。而文档根才是所有XML的根。选自 <<XML高级编程>>
－－－－－－－－－－－－－－－－－－－－－
其实就是：document root 和document element的区别了。
yoken 2003-09-01
- 打赏
- 举报
which appears in the document before that node, except ancestors, attribute nodes, or namespace nodes. One way to think of this is that preceding nodes are those whose content occurs in its entirety before the start of the node in question. Since the root node contains all other nodes in the document, it will never be located among a given node's preceding nodes; likewise, the root node itself has no preceding nodes. Given the document diagrammed earlier in this topic, for example:
The root <books> element has only one preceding node, which is the <?xml-stylesheet?> processing instruction.
Everything in the document (except the attributes and the document root node) is a preceding node relative to the concluding comment.
The first <author> element's preceding nodes are the comment, "Are we sure this guy's name is spelled right???", the first <title> element and its text node ("Jambing on the Trixles"), and the <?xml-stylesheet?> processing instruction. Since they are ancestors of the first <author> element, the first <book> element, the root <books> element, and the root node all terminate after the first <author> element closes, therefore they are not among its preceding nodes.
Following
Following nodes are the reverse of preceding ones: They include any nodes (except descendant, attribute, and namespace nodes) which come after a given node. Since the root node contains all other nodes in the document, it is a following node of none of them, and itself has no following nodes.
Based on the document diagrammed in this topic, we can say:
The root <books> element has only one following node, which is the document's concluding comment.
The concluding comment has no following nodes.
The first <author> element's following nodes are the second <book> element (and all of the second <book> element's descendants) and the concluding comment. Because the text node "Randall, Tristan" is a descendant (specifically, a child) of the first <author> element, it is not considered a following node for that element.
Preceding-sibling
Sibling relationships in a family identify children of the same parent, relative to one another. Therefore preceding-sibling nodes are a subset of all siblings, including only those which appear in the document before the node in question. Since attribute and namespace nodes can never be child nodes, they can never be found among a given nodes' preceding-siblings.
Note XPath does not define a simple sibling relationship, only preceding-sibling and following-sibling.
For instance, referring to the document described earlier in this topic:
Each of the <author> elements has one preceding-sibling node, which is the respective <title> element. However, the first <author> element also has another preceding-sibling, which is the comment, "Are we sure this guy's name is spelled right???"
The root <books> element has one preceding-sibling, the <?xml-stylesheet?> processing instruction.
The concluding comment has two preceding-siblings: the root <books> element and the <?xml-stylesheet?> processing instruction.
Following-sibling
Among a given node's following-siblings, you will find all those nodes (except attribute and namespace nodes, which can never be child nodes) which share that node's parent and appear after the node in question in the document.
Note XPath does not define a simple sibling relationship, only preceding-sibling and following-sibling.
Examples from the document diagrammed earlier in this topic include:
Neither of the <author> elements has any following-sibling nodes.
The root <books> element has one following-sibling, which is the concluding comment.
The concluding comment has no following-siblings.
Self
In some cases, you need an XPath expression which locates only the node you're already dealing with. For such cases, XPath provides the "self relationship." Every node in any given document has, of course, one and only one self node.
Attribute
Since attributes can never be found among the parent, child, ancestor, descendant, preceding, following, preceding-sibling, or following-sibling nodes of a given node, how do you locate them with XPath? The answer lies in the special attribute relationship. An element's attribute nodes are any attributes which it declares, and only elements can have attribute nodes.
Note A processing instruction's pseudo-attributes cannot be located this way.
Using the sample document diagrammed earlier in this topic, for instance:
Each of the <book> elements has a single attribute node, the respective catnum attribute.
The root <books> element likewise has one attribute node, the catdate attribute.
None of the other elements in this sample document have any attribute nodes.
Namespace
An element has a namespace node for every namespace which is in scope for it. Because namespaces are implicitly inherited by all elements descended from an element which declares a namespace, the following hold true:
An element may have a namespace node even if the element does not itself declare a namespace.
An element may have multiple namespace nodes, one corresponding to each namespace that it declares and one corresponding to each namespace declared by an ancestor element.
See Also
Sample XML File for XPath Tree Model
---------------------------
/ is the xml document's root node, the type of which is NODE_DOCUMENT
<root> is the xml document's root element, the type of which is NODE_ELEMENT
/ is the parent node of <root>
The root <books> element has only one preceding node, which is the <?xml-stylesheet?> processing instruction.
Everything in the document (except the attributes and the document root node) is a preceding node relative to the concluding comment.
The first <author> element's preceding nodes are the comment, "Are we sure this guy's name is spelled right???", the first <title> element and its text node ("Jambing on the Trixles"), and the <?xml-stylesheet?> processing instruction. Since they are ancestors of the first <author> element, the first <book> element, the root <books> element, and the root node all terminate after the first <author> element closes, therefore they are not among its preceding nodes.
Following
Following nodes are the reverse of preceding ones: They include any nodes (except descendant, attribute, and namespace nodes) which come after a given node. Since the root node contains all other nodes in the document, it is a following node of none of them, and itself has no following nodes.
Based on the document diagrammed in this topic, we can say:
The root <books> element has only one following node, which is the document's concluding comment.
The concluding comment has no following nodes.
The first <author> element's following nodes are the second <book> element (and all of the second <book> element's descendants) and the concluding comment. Because the text node "Randall, Tristan" is a descendant (specifically, a child) of the first <author> element, it is not considered a following node for that element.
Preceding-sibling
Sibling relationships in a family identify children of the same parent, relative to one another. Therefore preceding-sibling nodes are a subset of all siblings, including only those which appear in the document before the node in question. Since attribute and namespace nodes can never be child nodes, they can never be found among a given nodes' preceding-siblings.
Note XPath does not define a simple sibling relationship, only preceding-sibling and following-sibling.
For instance, referring to the document described earlier in this topic:
Each of the <author> elements has one preceding-sibling node, which is the respective <title> element. However, the first <author> element also has another preceding-sibling, which is the comment, "Are we sure this guy's name is spelled right???"
The root <books> element has one preceding-sibling, the <?xml-stylesheet?> processing instruction.
The concluding comment has two preceding-siblings: the root <books> element and the <?xml-stylesheet?> processing instruction.
Following-sibling
Among a given node's following-siblings, you will find all those nodes (except attribute and namespace nodes, which can never be child nodes) which share that node's parent and appear after the node in question in the document.
Note XPath does not define a simple sibling relationship, only preceding-sibling and following-sibling.
Examples from the document diagrammed earlier in this topic include:
Neither of the <author> elements has any following-sibling nodes.
The root <books> element has one following-sibling, which is the concluding comment.
The concluding comment has no following-siblings.
Self
In some cases, you need an XPath expression which locates only the node you're already dealing with. For such cases, XPath provides the "self relationship." Every node in any given document has, of course, one and only one self node.
Attribute
Since attributes can never be found among the parent, child, ancestor, descendant, preceding, following, preceding-sibling, or following-sibling nodes of a given node, how do you locate them with XPath? The answer lies in the special attribute relationship. An element's attribute nodes are any attributes which it declares, and only elements can have attribute nodes.
Note A processing instruction's pseudo-attributes cannot be located this way.
Using the sample document diagrammed earlier in this topic, for instance:
Each of the <book> elements has a single attribute node, the respective catnum attribute.
The root <books> element likewise has one attribute node, the catdate attribute.
None of the other elements in this sample document have any attribute nodes.
Namespace
An element has a namespace node for every namespace which is in scope for it. Because namespaces are implicitly inherited by all elements descended from an element which declares a namespace, the following hold true:
An element may have a namespace node even if the element does not itself declare a namespace.
An element may have multiple namespace nodes, one corresponding to each namespace that it declares and one corresponding to each namespace declared by an ancestor element.
See Also
Sample XML File for XPath Tree Model
---------------------------
/ is the xml document's root node, the type of which is NODE_DOCUMENT
<root> is the xml document's root element, the type of which is NODE_ELEMENT
/ is the parent node of <root>
yoken 2003-09-01
- 打赏
- 举报
and
--------------------
Microsoft XML Core Services (MSXML) 4.0 - XPath Developer's Guide
See Also
Sample XML File for XPath Tree Model
Overview of XPath Axes and Node Relationships
In addition to knowing the seven types of nodes, you also need to understand the possible kinds of relationships between and among nodes in a document. Each relationship corresponds to what XPath calls an axis. For more information, see Use XPath Axes to Navigate through XML Data.
The terms used for the axes assume that the document tree represents a set of family relationships. The axes that can be expressed with XPath are:
Parent
Child
Ancestor
Descendant
Ancestor-or-self
Descendant-or-self
Preceding
Following
Preceding-sibling
Following-sibling
Self
Two additional relationships apply only to element nodes:
Attribute
Namespace
Parent
The parent node of an element, attribute, processing instruction, comment, or text node is the element immediately above it in the tree—the element which contains it. For the root element, and any comments or processing instructions which precede or follow it, the parent is the root node. The root node itself has no parent. The parent of a namespace node is the element which declares it. In the document diagrammed above, for instance:
The parent of the <books> element is the root node.
The parent of each of the catnum attributes is the corresponding <book> element.
The parent of the comment, "Are we sure this guy's name is spelled right???" is the first <book> element.
The parent of both the <?xsl-stylesheet?> processing instruction and the comment at the end of the document is the root node.
Child
A node's child is any node immediately below it in the hierarchy of a document's nodes, with some exceptions. The exceptions are that neither attribute nor namespace nodes are considered children of their respective elements. Therefore, if an XPath expression locates all children of a given element, it locates only elements, text nodes, processing instructions, and comments immediately subordinate to that element.
processing instructions and comments in the document prolog or following the root element are considered children of the root node, as is the root element.
In the document diagrammed above, for instance:
The children of the root node are the <?xsl-stylesheet?> processing instruction, the root <books> element, and the comment which follows the root element's end tag.
The children of the <books> element node are the two <book> elements. Note that the catdate attribute is not considered a child of the <books> element node, despite the fact that <books> is considered catdate's parent.
The children of the first <book> element are the first <title> element, the comment "Are we sure this guy's name is spelled right???" and the first <author> element.
The second <title> element has only one child, the text node "For Love of a Toothpick."
Ancestor
An ancestor of any node in the tree is any node at a higher level in the tree than the node in question, including its parent. The root node has no ancestors; on the other hand, the root node is an ancestor of all other nodes in the tree.
For example, in the previous document diagrammed above:
The catdate attribute's ancestors are the <books> element and the root node.
The <?xml-stylesheet?> processing instruction, the root <books> element, and the comment following the <books> element each has a single ancestor, the root node.
Ancestors of the text node "Frey, Jörg" are the second <author> element, the second <book> element, the root <books> element, and the root node.
Descendant
A descendant node is any node (including children) which is subordinate to a given node in the document tree. Everything in the document tree is a descendant of the root node, except the root node itself and any attribute or namespace nodes.
For example, in the document diagrammed earlier in this topic:
The catdate and catnum attributes have no descendants. (Attributes have no children.)
Descendants of the first <book> element are the first <title> element and its text node, "Jambing on the Trixles"; the comment, "Are we sure this guy's name is spelled right???"; and the first <author> element and its text node, "Randall, Tristan." Since an attribute is not considered a child of its defining element, the catnum="id2345" attribute is not a descendant of this <book> element (or indeed of anything else in the document).
Ancestor-or-self
Ancestor-or-self nodes of a given node in the tree include all ancestors of that node and the node itself. Therefore, although the root node has no ancestors, an XPath expression which locates the ancestor-or-self nodes of the root node will locate the root node itself.
Some examples from the document diagrammed in this topic are:
The ancestor-or-self nodes of the concluding comment include the root node and the comment itself.
The catdate attribute's ancestor-or-self nodes are the <books> element which defines it, the root node, and the catdate attribute itself.
Descendant-or-self
If a given node in the tree has any descendants, an XPath expression locating its descendant-or-self nodes will locate all those descendants, and the node itself. If it has no descendants, such an expression will locate only the node itself. Thus, given the document diagrammed in this topic:
The second <title> element's descendant-or-self nodes are its text node, "For Love of a Toothpick," and that <title> element itself.
The document's concluding comment has no descendants; therefore it has only a single descendant-or-self node, which is the comment itself.
Preceding
A preceding node, relative to a given node in the document tree, is any node
--------------------
Microsoft XML Core Services (MSXML) 4.0 - XPath Developer's Guide
See Also
Sample XML File for XPath Tree Model
Overview of XPath Axes and Node Relationships
In addition to knowing the seven types of nodes, you also need to understand the possible kinds of relationships between and among nodes in a document. Each relationship corresponds to what XPath calls an axis. For more information, see Use XPath Axes to Navigate through XML Data.
The terms used for the axes assume that the document tree represents a set of family relationships. The axes that can be expressed with XPath are:
Parent
Child
Ancestor
Descendant
Ancestor-or-self
Descendant-or-self
Preceding
Following
Preceding-sibling
Following-sibling
Self
Two additional relationships apply only to element nodes:
Attribute
Namespace
Parent
The parent node of an element, attribute, processing instruction, comment, or text node is the element immediately above it in the tree—the element which contains it. For the root element, and any comments or processing instructions which precede or follow it, the parent is the root node. The root node itself has no parent. The parent of a namespace node is the element which declares it. In the document diagrammed above, for instance:
The parent of the <books> element is the root node.
The parent of each of the catnum attributes is the corresponding <book> element.
The parent of the comment, "Are we sure this guy's name is spelled right???" is the first <book> element.
The parent of both the <?xsl-stylesheet?> processing instruction and the comment at the end of the document is the root node.
Child
A node's child is any node immediately below it in the hierarchy of a document's nodes, with some exceptions. The exceptions are that neither attribute nor namespace nodes are considered children of their respective elements. Therefore, if an XPath expression locates all children of a given element, it locates only elements, text nodes, processing instructions, and comments immediately subordinate to that element.
processing instructions and comments in the document prolog or following the root element are considered children of the root node, as is the root element.
In the document diagrammed above, for instance:
The children of the root node are the <?xsl-stylesheet?> processing instruction, the root <books> element, and the comment which follows the root element's end tag.
The children of the <books> element node are the two <book> elements. Note that the catdate attribute is not considered a child of the <books> element node, despite the fact that <books> is considered catdate's parent.
The children of the first <book> element are the first <title> element, the comment "Are we sure this guy's name is spelled right???" and the first <author> element.
The second <title> element has only one child, the text node "For Love of a Toothpick."
Ancestor
An ancestor of any node in the tree is any node at a higher level in the tree than the node in question, including its parent. The root node has no ancestors; on the other hand, the root node is an ancestor of all other nodes in the tree.
For example, in the previous document diagrammed above:
The catdate attribute's ancestors are the <books> element and the root node.
The <?xml-stylesheet?> processing instruction, the root <books> element, and the comment following the <books> element each has a single ancestor, the root node.
Ancestors of the text node "Frey, Jörg" are the second <author> element, the second <book> element, the root <books> element, and the root node.
Descendant
A descendant node is any node (including children) which is subordinate to a given node in the document tree. Everything in the document tree is a descendant of the root node, except the root node itself and any attribute or namespace nodes.
For example, in the document diagrammed earlier in this topic:
The catdate and catnum attributes have no descendants. (Attributes have no children.)
Descendants of the first <book> element are the first <title> element and its text node, "Jambing on the Trixles"; the comment, "Are we sure this guy's name is spelled right???"; and the first <author> element and its text node, "Randall, Tristan." Since an attribute is not considered a child of its defining element, the catnum="id2345" attribute is not a descendant of this <book> element (or indeed of anything else in the document).
Ancestor-or-self
Ancestor-or-self nodes of a given node in the tree include all ancestors of that node and the node itself. Therefore, although the root node has no ancestors, an XPath expression which locates the ancestor-or-self nodes of the root node will locate the root node itself.
Some examples from the document diagrammed in this topic are:
The ancestor-or-self nodes of the concluding comment include the root node and the comment itself.
The catdate attribute's ancestor-or-self nodes are the <books> element which defines it, the root node, and the catdate attribute itself.
Descendant-or-self
If a given node in the tree has any descendants, an XPath expression locating its descendant-or-self nodes will locate all those descendants, and the node itself. If it has no descendants, such an expression will locate only the node itself. Thus, given the document diagrammed in this topic:
The second <title> element's descendant-or-self nodes are its text node, "For Love of a Toothpick," and that <title> element itself.
The document's concluding comment has no descendants; therefore it has only a single descendant-or-self node, which is the comment itself.
Preceding
A preceding node, relative to a given node in the document tree, is any node
yoken 2003-09-01
- 打赏
- 举报
according to
------------------
Microsoft XML Core Services (MSXML) 4.0 - DOM Reference
See Also
Applies to: IXMLDOMAttribute | IXMLDOMCDATASection | IXMLDOMCharacterData | IXMLDOMComment | DOMDocument | IXMLDOMDocumentFragment | IXMLDOMDocumentType | IXMLDOMElement | IXMLDOMEntity | IXMLDOMEntityReference | IXMLDOMNode | IXMLDOMNotation | IXMLDOMProcessingInstruction | IXMLDOMText | XML DOM Enumerated Constants
Language
C/C++
Script
Visual Basic
Show All
nodeType Property [Script]
Specifies the XML Document Object Model (DOM) node type, which determines valid values and whether the node can have child nodes.
[Script]
Script Syntax
lValue = oXMLDOMNode.nodeType;
Example
The following script example creates an IXMLDOMNode object and displays its type enumeration, in this case, 1 for NODE_ELEMENT.
var xmlDoc = new ActiveXObject("Msxml2.DOMDocument.4.0");
var currNode;
xmlDoc.async = false;
xmlDoc.load("books.xml");
currNode = xmlDoc.documentElement.childNodes.item(0);
alert(currNode.nodeType);
[Visual Basic]
Visual Basic Syntax
lValue = oXMLDOMNode.nodeType
Example
The following Microsoft® Visual Basic® example creates an IXMLDOMNode object and displays its type enumeration, in this case, 1 for NODE_ELEMENT.
Dim xmlDoc As New Msxml2.DOMDocument40
Dim currNode As IXMLDOMNode
xmlDoc.async = False
xmlDoc.Load ("books.xml")
Set currNode = xmlDoc.documentElement.childNodes.Item(0)
MsgBox currNode.nodeType
[C/C++]
C/C++ Syntax
HRESULT get_nodeType(
DOMNodeType *type);
Parameters
type [out, retval]
Type of the node.
C/C++ Return Values
S_OK
Value returned if successful.
E_INVALIDARG
Value returned if the type parameter is Null.
Remarks
Enumeration. The property is read-only. It indicates the type of the node. Use the nodeTypeString property to return the node type in string form.
The IXMLDOMNodeType enumeration defines the following valid values that can appear in the nodeType property.
NODE_ELEMENT (1) The node represents an element. An element node can have the following child node types: Element, Text, Comment, ProcessingInstruction, CDATASection, and EntityReference. An element node can be the child of the Document, DocumentFragment, EntityReference, and Element nodes.
NODE_ATTRIBUTE (2) The node represents an attribute of an element. An attribute node can have the following child node types: Text and EntityReference. An attribute does not appear as the child node of any other node type; note that it is not considered a child node of an element.
NODE_TEXT (3) The node represents the text content of a tag. A text node cannot have any child nodes. A text node can appear as the child node of the Attribute, DocumentFragment, Element, and EntityReference nodes.
NODE_CDATA_SECTION (4) The node represents a CDATA section in the XML source. CDATA sections are used to escape blocks of text that would otherwise be recognized as markup. A CDATA section node cannot have any child nodes. A CDATA section node can appear as the child of the DocumentFragment, EntityReference, and Element nodes.
NODE_ENTITY_REFERENCE (5) The node represents a reference to an entity in the XML document. This applies to all entities, including character entity references. An entity reference node can have the following child node types: Element, ProcessingInstruction, Comment, Text, CDATASection, and EntityReference. An entity reference node can appear as the child of the Attribute, DocumentFragment, Element, and EntityReference nodes.
NODE_ENTITY (6) The node represents an expanded entity. An entity node can have child nodes that represent the expanded entity (for example, Text and EntityReference nodes). An entity node can appear as the child of the DocumentType node.
NODE_PROCESSING_INSTRUCTION (7) The node represents a processing instruction from the XML document. A processing instruction node cannot have any child nodes. A processing instruction node can appear as the child of the Document, DocumentFragment, Element, and EntityReference nodes.
NODE_COMMENT (8) The node represents a comment in the XML document. A comment node cannot have any child nodes. A comment node can appear as the child of Document, DocumentFragment, Element, and EntityReference nodes.
NODE_DOCUMENT (9) The node represents a document object, which, as the root of the document tree, provides access to the entire XML document. It is created using the progID "Msxml2.DOMDocument", or through a data island using <XML> or <SCRIPT LANGUAGE=XML>. A document node can have the following child node types: Element (maximum of one), ProcessingInstruction, Comment, and DocumentType. A document node cannot appear as the child of any node types.
NODE_DOCUMENT_TYPE (10) The node represents the document type declaration, indicated by the <!DOCTYPE > tag. A document type node can have the following child node types: Notation and Entity. A document type node can appear as the child of the Document node.
NODE_DOCUMENT_FRAGMENT (11) The node represents a document fragment. A document fragment node associates a node or subtree with a document without actually being contained within the document. A document fragment node can have the following child node types: Element, ProcessingInstruction, Comment, Text, CDATASection, and EntityReference. A DocumentFragment node cannot appear as the child of any node types.
NODE_NOTATION (12) A node represents a notation in the document type declaration. A notation node cannot have any child nodes. A notation node can appear as the child of the DocumentType node.
To view reference information for Visual Basic, C/C++, or Script only, click the Language Filter button in the upper-left corner of the page.
See Also
Applies to: IXMLDOMAttribute | IXMLDOMCDATASection | IXMLDOMCharacterData | IXMLDOMComment | DOMDocument | IXMLDOMDocumentFragment | IXMLDOMDocumentType | IXMLDOMElement | IXMLDOMEntity | IXMLDOMEntityReference | IXMLDOMNode | IXMLDOMNotation | IXMLDOMProcessingInstruction | IXMLDOMText | XML DOM Enumerated Constants
------------------
Microsoft XML Core Services (MSXML) 4.0 - DOM Reference
See Also
Applies to: IXMLDOMAttribute | IXMLDOMCDATASection | IXMLDOMCharacterData | IXMLDOMComment | DOMDocument | IXMLDOMDocumentFragment | IXMLDOMDocumentType | IXMLDOMElement | IXMLDOMEntity | IXMLDOMEntityReference | IXMLDOMNode | IXMLDOMNotation | IXMLDOMProcessingInstruction | IXMLDOMText | XML DOM Enumerated Constants
Language
C/C++
Script
Visual Basic
Show All
nodeType Property [Script]
Specifies the XML Document Object Model (DOM) node type, which determines valid values and whether the node can have child nodes.
[Script]
Script Syntax
lValue = oXMLDOMNode.nodeType;
Example
The following script example creates an IXMLDOMNode object and displays its type enumeration, in this case, 1 for NODE_ELEMENT.
var xmlDoc = new ActiveXObject("Msxml2.DOMDocument.4.0");
var currNode;
xmlDoc.async = false;
xmlDoc.load("books.xml");
currNode = xmlDoc.documentElement.childNodes.item(0);
alert(currNode.nodeType);
[Visual Basic]
Visual Basic Syntax
lValue = oXMLDOMNode.nodeType
Example
The following Microsoft® Visual Basic® example creates an IXMLDOMNode object and displays its type enumeration, in this case, 1 for NODE_ELEMENT.
Dim xmlDoc As New Msxml2.DOMDocument40
Dim currNode As IXMLDOMNode
xmlDoc.async = False
xmlDoc.Load ("books.xml")
Set currNode = xmlDoc.documentElement.childNodes.Item(0)
MsgBox currNode.nodeType
[C/C++]
C/C++ Syntax
HRESULT get_nodeType(
DOMNodeType *type);
Parameters
type [out, retval]
Type of the node.
C/C++ Return Values
S_OK
Value returned if successful.
E_INVALIDARG
Value returned if the type parameter is Null.
Remarks
Enumeration. The property is read-only. It indicates the type of the node. Use the nodeTypeString property to return the node type in string form.
The IXMLDOMNodeType enumeration defines the following valid values that can appear in the nodeType property.
NODE_ELEMENT (1) The node represents an element. An element node can have the following child node types: Element, Text, Comment, ProcessingInstruction, CDATASection, and EntityReference. An element node can be the child of the Document, DocumentFragment, EntityReference, and Element nodes.
NODE_ATTRIBUTE (2) The node represents an attribute of an element. An attribute node can have the following child node types: Text and EntityReference. An attribute does not appear as the child node of any other node type; note that it is not considered a child node of an element.
NODE_TEXT (3) The node represents the text content of a tag. A text node cannot have any child nodes. A text node can appear as the child node of the Attribute, DocumentFragment, Element, and EntityReference nodes.
NODE_CDATA_SECTION (4) The node represents a CDATA section in the XML source. CDATA sections are used to escape blocks of text that would otherwise be recognized as markup. A CDATA section node cannot have any child nodes. A CDATA section node can appear as the child of the DocumentFragment, EntityReference, and Element nodes.
NODE_ENTITY_REFERENCE (5) The node represents a reference to an entity in the XML document. This applies to all entities, including character entity references. An entity reference node can have the following child node types: Element, ProcessingInstruction, Comment, Text, CDATASection, and EntityReference. An entity reference node can appear as the child of the Attribute, DocumentFragment, Element, and EntityReference nodes.
NODE_ENTITY (6) The node represents an expanded entity. An entity node can have child nodes that represent the expanded entity (for example, Text and EntityReference nodes). An entity node can appear as the child of the DocumentType node.
NODE_PROCESSING_INSTRUCTION (7) The node represents a processing instruction from the XML document. A processing instruction node cannot have any child nodes. A processing instruction node can appear as the child of the Document, DocumentFragment, Element, and EntityReference nodes.
NODE_COMMENT (8) The node represents a comment in the XML document. A comment node cannot have any child nodes. A comment node can appear as the child of Document, DocumentFragment, Element, and EntityReference nodes.
NODE_DOCUMENT (9) The node represents a document object, which, as the root of the document tree, provides access to the entire XML document. It is created using the progID "Msxml2.DOMDocument", or through a data island using <XML> or <SCRIPT LANGUAGE=XML>. A document node can have the following child node types: Element (maximum of one), ProcessingInstruction, Comment, and DocumentType. A document node cannot appear as the child of any node types.
NODE_DOCUMENT_TYPE (10) The node represents the document type declaration, indicated by the <!DOCTYPE > tag. A document type node can have the following child node types: Notation and Entity. A document type node can appear as the child of the Document node.
NODE_DOCUMENT_FRAGMENT (11) The node represents a document fragment. A document fragment node associates a node or subtree with a document without actually being contained within the document. A document fragment node can have the following child node types: Element, ProcessingInstruction, Comment, Text, CDATASection, and EntityReference. A DocumentFragment node cannot appear as the child of any node types.
NODE_NOTATION (12) A node represents a notation in the document type declaration. A notation node cannot have any child nodes. A notation node can appear as the child of the DocumentType node.
To view reference information for Visual Basic, C/C++, or Script only, click the Language Filter button in the upper-left corner of the page.
See Also
Applies to: IXMLDOMAttribute | IXMLDOMCDATASection | IXMLDOMCharacterData | IXMLDOMComment | DOMDocument | IXMLDOMDocumentFragment | IXMLDOMDocumentType | IXMLDOMElement | IXMLDOMEntity | IXMLDOMEntityReference | IXMLDOMNode | IXMLDOMNotation | IXMLDOMProcessingInstruction | IXMLDOMText | XML DOM Enumerated Constants
JGTM2000 2003-08-30
- 打赏
- 举报
to: aviatorbai(皓臣)
You're wrong at this point, or at least issuing wrong terminology. The "/" in XPath's semantics denotes an XML document's "root node" (it's a NODE of type "root") whereas the unique "<root>" element is called an XML document's "document element" (it's a NODE of type "element", and it's also known as the document's "root element"). The "/" node is the parent node of the unique document element node. The intrinsic root node "/" provides you access to the entire XML document (so you know why XSLT processors always start from "/".)
According to this definition and XML document's standard, in every valid XML document, there is only one "/" root node and there is one and only one child node (the document element) below the root node.
BTW, in .NET Framework, the "/" node's type is XmlNodeType.Document whereas "<root>" node's type is always a more generic XmlNodeType.Element.
Any comments? Thanks. :)
You're wrong at this point, or at least issuing wrong terminology. The "/" in XPath's semantics denotes an XML document's "root node" (it's a NODE of type "root") whereas the unique "<root>" element is called an XML document's "document element" (it's a NODE of type "element", and it's also known as the document's "root element"). The "/" node is the parent node of the unique document element node. The intrinsic root node "/" provides you access to the entire XML document (so you know why XSLT processors always start from "/".)
According to this definition and XML document's standard, in every valid XML document, there is only one "/" root node and there is one and only one child node (the document element) below the root node.
BTW, in .NET Framework, the "/" node's type is XmlNodeType.Document whereas "<root>" node's type is always a more generic XmlNodeType.Element.
Any comments? Thanks. :)
aviatorbai 2003-08-29
- 打赏
- 举报
非也！
在xml中的xpath的template总，match在英文中是：context。就是上下文的意思。按我的理解就是:
/：表示的是root node那一个层次。并不是特指root node，他也表示在root node那个层次的所有东西。记住，他不表示任何节点，只是一个层次（即上下文context）。
好了，你要表示跟节点，可以用：/root就可以了。
在xml中的xpath的template总，match在英文中是：context。就是上下文的意思。按我的理解就是:
/：表示的是root node那一个层次。并不是特指root node，他也表示在root node那个层次的所有东西。记住，他不表示任何节点，只是一个层次（即上下文context）。
好了，你要表示跟节点，可以用：/root就可以了。
aviatorbai 2003-08-29
- 打赏
- 举报
Microsoft XML 4.0 Technology Preview - XSLT Reference
Sample Tree for the Document Root
At the most obvious structural level, the "tree" which XPath can wander through the Sample XML File for XPath Tree Model consists of the document prolog—the XML declaration, the document-type declaration, and the <?xml-stylesheet?> PI—the root element <books>, and the comment which follows the root element's end tag.
Schematically, this tree might be represented like this:
Each of these containers is referred to in XPath terms as a node, and a collection of nodes as a node-set. In the above figure, there are four nodes accessible to most XSLT processors, including the MSXML engine:
The document root node
The <?xml-stylesheet?> processing-instruction node
The <books> element node
The comment node following the <books> element
Note The XML declaration and the document-type declaration are not typically accessible. This is because by the time an XSLT processor gets access to the document tree, the document has been fully parsed; information in the XML and document-type declarations is assumed to be useful to the parser but not passed to a downstream application.
See Also
Sample XML File for XPath Tree Model
See Also
Sample XML File for XPath Tree Model
Sample Tree for the Document Root
At the most obvious structural level, the "tree" which XPath can wander through the Sample XML File for XPath Tree Model consists of the document prolog—the XML declaration, the document-type declaration, and the <?xml-stylesheet?> PI—the root element <books>, and the comment which follows the root element's end tag.
Schematically, this tree might be represented like this:
Each of these containers is referred to in XPath terms as a node, and a collection of nodes as a node-set. In the above figure, there are four nodes accessible to most XSLT processors, including the MSXML engine:
The document root node
The <?xml-stylesheet?> processing-instruction node
The <books> element node
The comment node following the <books> element
Note The XML declaration and the document-type declaration are not typically accessible. This is because by the time an XSLT processor gets access to the document tree, the document has been fully parsed; information in the XML and document-type declarations is assumed to be useful to the parser but not passed to a downstream application.
See Also
Sample XML File for XPath Tree Model
See Also
Sample XML File for XPath Tree Model
aviatorbai 2003-08-29
- 打赏
- 举报
XML File (booksxpath.xml)
<?xml version="1.0" ?>
<!DOCTYPE books [
<!ENTITY oumlaut "ö">
]>
<?xml-stylesheet type="text/xsl" href="catalog.xsl" ?>
<books catdate="2000-12-31">
<book catnum="id2345">
<title>Jambing on the Trixles</title>
<!-- Are we sure this guy's name is spelled right??? -->
<author>Randall, Tristan</author>
</book>
<book catnum="id7823">
<title>For Love of a Toothpick</title>
<author>Frey, Jöaut;rg</author>
</book>
</books>
<!-- Reviewed by Catalog Department 2000-12-30 09:11:16 -->
<?xml version="1.0" ?>
<!DOCTYPE books [
<!ENTITY oumlaut "ö">
]>
<?xml-stylesheet type="text/xsl" href="catalog.xsl" ?>
<books catdate="2000-12-31">
<book catnum="id2345">
<title>Jambing on the Trixles</title>
<!-- Are we sure this guy's name is spelled right??? -->
<author>Randall, Tristan</author>
</book>
<book catnum="id7823">
<title>For Love of a Toothpick</title>
<author>Frey, Jöaut;rg</author>
</book>
</books>
<!-- Reviewed by Catalog Department 2000-12-30 09:11:16 -->
saucer 2003-08-28
- 打赏
- 举报
yes
yoken 2003-08-28
- 打赏
- 举报
saucer说的意思是不是
/是document root node
<COLLECTION>是top level elment，俗称root node
/是<COLLECTION>的parent node
/是document root node
<COLLECTION>是top level elment，俗称root node
/是<COLLECTION>的parent node
saucer 2003-08-28
- 打赏
- 举报
"/" is called document root, the parent node of your top level element, which is traditionally called "root node"
孟子E章 2003-08-28
- 打赏
- 举报
/就是标识根的
