Generally, the XML file we have seen is based on the elements. With the continuous deepening of the level, it gradually became a tree. The advantage of this document is that we look at the son, father, ancestors, brothers. Relationship, inconvenience, I personally think that if the level is very deep, there is a lot of brothers nodes, then the document may be large and affecting the efficiency of processing. Due to the flexibility of describing the data structure, an attribute value is used in some environments to describe the relationship between elements. For example, the TOC (Table of Content) on the left side of the garden, implements its XML file through the attribute value to explain the type of elements (Node or Leaf), but there is still a sub-node, so it is used to transform its XSL file is very complicated. Divided several situations. Of course, today we are not talking about the implementation of the garden TOC but to achieve similar TOCs in a faster, harder approach, and of course it can also be called "tree folding navigation bar". Ok, talk less nonsense, enter the topic. Let's take a very simple DTD. Navigator.dtd
file is very simple, it can be understood, top-level elements Navigation Contains multiple Navigator elements defined, Navigator does not contain elements but have a series of properties. Maybe you have discovered that there are two of the attributes called Ancestorid Childs, yes, these two attributes are the key, of course, there is a Layer, under their common action, the relationship between Navigator elements will be explicitly described. Ok, let's look at the Navi.xml file, as an example of garden TOC.
View garden TOC example: navi.xml Xml version = "1.0" encoding = "gb2312"?> Xml-stylesheet type = "text / xsl" href = "Navigator .xsl "?> '1' title = 'Personal Toolbox' CHilds = '2' URL = '#' Image = 'Default' /> The principle is this, good, let's take a look at this key navigator.xsl: XML version = "1.0" eNCoding = "GB2312"?>