Three _xml/rss of the simple XML tutorial

The future of XML
Now you already know XML. Indeed, the structure is somewhat complex, and the DTD has a variety of
To define the options for what the document can contain. But that's not all.

Consider an industry in which data exchange is important to them, such as banks. Banks use all
Power system to track internal transactions, but if they use a generic
XML format, then they must describe the transaction information to another organization or application
Order (such as Quicken or Ms Money). Of course, they can also be on the Web page
Represents the data. FYI: This tag does not exist. It's called Ofex, opening up financial transactions.
Format (Open Financial Exchange).

In some cases, if IE 4 on the PC encounters a <SOFTPKG> tag, a
Functions are started to give users the opportunity to update installed software. If you use
Is Windows 98, you may have seen this, but don't know it is a
XML application.

Here we have three XML apps that look with Andy Grove in the 70 's
The addition machine, the typewriter and the pencil are different. But with the final appearance on the PC should
Similar to programs, the benefits of XML can be generally described as: "When you use people
A good thing happens when a class and a machine-readable tag describe your data. ”

What are these good things? I do not know. But I don't know the bottom of my PC
What a generation of programs will be like. As long as the data is marked in this way, you can generate
Different applications.

Are you starting to think about how far it's going to expand?

We have a lot of XML practical applications to talk about and I'll talk about it in the near future
Our. Since we are all netizens, we will be XSL (extended style language-
Extensible Style Language).

By the way, this recipe is really my mother's, and very outstanding. If you
With it, add half a cup of broken coconut.

I am writing this article because I sincerely care about what you think of me. My concern is: if you have read the XML introduction I wrote, then you are ready to start writing your own XML document. So you start looking for an established DTD to represent your message. You find one, as follows:

<! ATTLIST fn

%attr.lang;

Value CDATA #FIXED "TEXT" >

<! ENTITY% attr.img "

Img.type CDATA #REQUIRED

Img.data ENTITY #REQUIRED ">

Soon you'll think Jay must be an idiot. He didn't say anything about attlist and entity-no matter what they were.

So let's talk about it with a bit of patience first.

These lines may not look good, but they are really nothing. They are used in DTDs to define attributes and entities in an XML document. People who know the HTML will be very clear about that. A property is an entry with an HTML tag to describe the tag more accurately. In the , there are two attributes: Height and width. As you'll see later, using attributes in XML documents is very similar.

There is nothing new about the entity. If you have used and, you have mastered the most basic things. A string surrounded by & and semicolon is used to represent another or set of characters. (Here is a complete list of ISO entities.) ）

Of course, attributes and entities in XML have other functions as well. This inevitably introduces syntax, though not too much. Once this is known, the XML document is used effortlessly.

Simplifying recipes

If you've read the XML introduction I wrote, you'll remember the ingredients in the recipe, such as <item>2 cups flour</item>, represented by a simple marker. After I finished writing that article, I roamed the web and found another XML document about the recipe. The recipe elements are as follows:

<ingredient quantity= "2" units= "cups" >flour</ingredient>

There is a real benefit to this approach: it makes it easier to control data. The first method,<item> a tag to hold a bunch of different information. I wouldn't do that if I wanted to extract the list of components without the amount of the ingredients.

I can use the following structure to get similar features:

<item>flour

<quantity>2</quantity>

<units>cups</units>

This can be handled, but there are two problems: first, the item element contains mixed content: text and other markers. I soon found that this structure should be avoided as much as possible. The second is that the marker has almost no independent meaning. It is hard to imagine a situation where units is not a real component. These items can be described briefly, and I would rather treat them as attributes.

The first thing to note is the attribute name, quantity and units are only meaningful when processed by the application that can translate them.

Before being included in a valid document, you should tell the DTD to allow it. For the ingredient element above, we include only the following code in the DTD:

<! ELEMENT ingredient #PCDATA >

<! Attlist ingredient quantity CDATA #REQUIRED >

<! Attlist ingredient units CDATA #REQUIRED >

The first line looks familiar-a standard element definition that can be seen in any DTD. Each attlist line contains the following information in turn:

<! Attlist ingredient quantity CDATA #REQUIRED >

This is the element on which the attribute is attached.

<! Attlist ingredient quantity CDATA #REQUIRED >

This defines the property name.

<! Attlist ingredient quantity CDATA #REQUIRED >

This sets the property type. CDATA represents character data. means that the processor can get text within the attribute.

<! Attlist ingredient quantity CDATA #REQUIRED >

The last section defines the default value for the property. You can use the actual numeric value, such as 3. In this way, the attribute value for the blank length in the XML will be 3. The value you enter overrides the default value.

In the example above I did not set a specific number, but instead used the keyword #required of XML. It tells the processor that the secondary attribute must contain a value. If blank, the document will not be processed.

The default value has two additional keywords. The first is #fixed-if the value of the property remains the same in the entire document. Suppose I define a tag property of image, and all images are of the same size, such as 100*50 pixels, which can be defined in a DTD:

<! attlist picture length CDATA #FIXED "px" >

<! Attlist picture width CDATA #FIXED "px" >

Another keyword is #implied, which means that the property can contain a value or empty.

Let's look at the attribute type below.

If you decide to write your own DTD, you may need a book that interprets all the combinations of XML in the ATTLIST statement. But if you borrow a DTD, you probably only know CDATA and three other attributes.

The first one is the ID. It requires that the value of the property not be duplicated in the document. Anyone who has ever used a database knows the need for a unique identifier. The DTD attlist statement looks like this:

<! Attlist element_name attribute_name ID #REQUIRED >

It is hard to imagine an id attribute type without a #required default value. If so, any duplicate or empty IDs will force the processor to return an error. The ID must start with a letter or underscore and cannot contain any spaces.

The NmToken type also uses the above naming convention. But allow duplication. It is used as a safeguard for passing data to applications. Most programming languages, including Java and JavaScript, cannot have spaces in the module name. In most cases, it is best to ensure that attributes conform to their rules.

Finally, the enumeration type does not require a specific keyword. But with "|" The symbol contains the values in parentheses, for example:

<! Attlist Sibling (brother | sister) #REQUIRED >

If you have a limited number of possible property values, you can do so in this way.

Don't think today's lesson is boring, then read it!