How old is xml

The actorid attribute has been designated an ID. In DTD-speak, an ID attribute must contain a unique value, which is handy for product codes, database keys, and other identifying factors. In our example, we want the actorid attribute to uniquely identify each actor in the list. The ID type set for the actorid attribute ensures that our XML document is valid if and only if a unique actorid is assigned to each actor. Incidentally, if you want to declare an attribute that must contain a reference to a unique ID that is assigned to an element somewhere in the document, you can declare it with the IDREF attribute type.

An entity is a piece of XML code that can be used and reused in a document with an entity reference. There are different types of entities, including general, parameter, and external. General entities are basically used as substitutes for commonly-used segments of XML code.

For example, here is an entity declaration that holds the copyright information for a company:. Parameter entities are both defined and referenced within DTDs. What this says is that each of the elements paragraph , intro , sidebar , and note can contain regular text as well as b , i , u , citation , and dialog elements.

Not only does the use of a parameter entity reduce typing, it also simplifies maintenance of the DTD. External entities point to external information that can be copied into your XML document at runtime. For example, you could include a stock ticker, inventory list, or other file, using an external entity.

An external DTD is usually a file with a file extension of. First, you must edit the XML declaration to include the attribute.

This will search for the letter. If the DTD lives on a Web server, you might point to that instead:. Finally, XML Schema provides very fine control over the kinds of data contained in an element or attribute. Most of the criticism aimed at XML Schema is focused on its complexity and length.

Okay, now you know a lot more about DTDs than you did before. The first thing you do is you take a look at the dozens of corporate memos you and your colleagues have received in the past few months. After a day or two of close examination, a pattern emerges. Although your first impulse might be to run out and create a sample XML memo document, please resist that urge for now.

Because these memos are internal to the company, and there may be a need for a separate external memo DOCTYPE, you decide to use internalmemo as your root element name:. The first element — the root element — is internalmemo. This element will contain all the other elements, which hold date, sender, recipient, subject line, and all other information.

Because these represent a lot of elements, it would be useful to split your document into two logical partitions: header and body. The header will contain recipient, subject line, date, and other information. The body will contain the actual text of the memo.

In DTD syntax, the above declaration states that our internalmemo element must contain one header element and one body element. Next, we will indicate which elements these will contain. In DTD syntax, the above declaration states that the header element must contain single date , sender , and recipients elements, an optional blind-recipients element, and then a subject element.

In DTD syntax, the above declaration states that the body element must contain one or more para elements, followed by a single sig element. Most of the other elements will contain plain text, except the para elements, in which we will allow bold and italic text formatting.

That was simple enough. Those pieces of information are hardly ever displayed on a document — they are used only for administrative purposes.

In any case, we want to be able to control the data that document creators put in for values such as priority. The best way to store these pieces of information is to add them as attributes to the root element. To do that, we need to add an attribute declaration to our DTD:. The result should look a lot like Figure 3. Figure 3. Validating our first case with Dreamweaver MX. Do you see how, under Results, it reads No errors or warnings found.?

In Dreamweaver MX , the results list for a valid document is simply empty, and the status bar beneath the list reads Complete. What happens if some things are out of place? What would happen then? Error resulting from a bad attribute value. Notice that Dreamweaver MX tells you where the problem lies with a specific line number and provides a description of the problem.

The validator catches that too, as you can see in Figure 3. Error resulting from a misplaced element. Again, the validator gives you a line number and a description that can lead you to resolve the problem. All you need to do is put the sender element back in the prescribed order, and the document will validate once more.

In that case, we embedded the DTD right into the file. You now have a reusable DTD that you can apply to other internal memos.

We now understand articles, news stories, binary files, and Web copy, and are well on our way to completing the requirements-gathering phase of the project — we can start coding soon! If you recall, we are tracking author, status, keyword, and other vital information in separate files.

That is, each individual article, news story, binary file, and Web copy file keeps track of its own keywords, status, author, and dates. If we wanted to display all documents for a certain author, we would have to dig through all of our files to find all the matches.

Never fear — I have a proposal that will solve this problem. In fact, the rest of this chapter will be devoted to tackling this issue. With any luck, it will also give you some insights into the ways in which you can analyze requirements and come up with more architecturally sound XML designs. The other problem is a little less obvious. To our application, these three names are different, and articles will thus be listed under three different authors.

To solve this problem, we should create a separate author listing authors. Once we have this figured out, we can get rid of the author element in all the other content types, and replace them with an authorid elements.

Handling our authors this way also allows us to track other information about authors, such as their email addresses, their bylines in case they want to publish under pseudonyms , and other such information. Instead of a separate author element, we would add an authorid element to our articles, like this:.

All we need to do is use this author ID in our articles, news stories, and all other content we add to our CMS; this ID is used to look up the author and retrieve the information we need. The big question remains: do we take the time and effort to create DTDs or schemas for each of our content types? To be completely honest, most articles, news stories, and such will be submitted to the site through our administrative tool.

This tool will have the necessary forms that will restrict data entry to certain fields. In other words, our administrative tool will do most of the work of validating our content. However, I think it would be good practice to develop a DTD for our article content type — after all, this is one of the most important document types we have in our system, and it has to be done right. Although we have declared our body element to contain character data, our article bodies will indeed be formatted using HTML tags.

Try writing DTDs for these as well. We used it to transform an XML letter to mother into something that could be displayed in a browser window. XPath is used in a variety of applications and technologies, however, XSLT is where its power and versatility really shine. For all intents and purposes, XPath is a query language. It uses a simple notation that is very similar to directory paths hence the name XPath.

When we put together a template, we normally use XPath to establish a match. For example, we can always handle the root of an XML document like this:. With XPath, you can select all elements that have a particular tag name. Or, you could match certain elements depending on their location within an XML file. As you can see, the basic XPath syntax looks a lot like a file path on your computer. But you can go a step further and set conditions on which elements are matched within your specified path.

These conditions are called predicates , and appear within square brackets following the element name you wish to set conditions for. The symbol identifies priority in this example as an attribute name, not a tag name. XPath also has a number of useful functions built in. For example, if you need to grab the first or last element of a series, you can use XPath to do so.

Although most practical applications are relatively simple, XPath can get quite twisty when it needs to be. The XPath Recommendation is quite a useful reference to these areas of complexity. Book chapters provide an excellent opportunity to understand the arbitrary complexity of most XML documents. From the perspective of an XML document designer, however, a book chapter can be intimidatingly complex. Chapters can have titles and sections, and those sections can have titles. There are paragraphs throughout — some belong to the chapter for example, introductory paragraphs , but others belong to sections.

Sections can contain subsections. Paragraphs can contain text in italics, bold text, and other inline markup. In fact, one could even have different types of paragraphs, like notes, warnings, and tips. There are lots of possibilities for displaying these kinds of information. This sample file could go on and on, but I think you get the idea. The first thing we want to do is to match the root of our document. Example 4.

Nothing could be simpler, right? Viewed in a browser, our output will look something like that shown in Figure 4. Figure 4. Viewing the chapter example in Firefox. Of course there is. The title element near the top of the document is the chapter title, and should be handled differently from the title elements in the different nested sections.

Likewise, para elements that denote warnings or introductions should be handled differently from other paragraphs. To distinguish between these different title types, you can use XPath notation.

Viewing the chapter example with XPath. Part 1. What about the paragraphs? Unlike the titles, they are not distinguishable by their placement in the document alone. Instead, the document uses the type attribute to distinguish normal paragraphs from introductions, tips, and warnings. Luckily, XPath lets us specify matches based on attribute values, too. In XPath, we use a predicate a condition in square brackets to match an attribute value.

We should definitely take advantage of this ability and distinguish each of our paragraph types visually. We can also make sure that warnings are displayed in red text. Note the priority attribute on this template. By default, XSL templates have a priority between To make sure our introductory paragraphs will use this second template, we therefore assign a priority of 1. How can we modify our template to display the actual chapter title in this spot instead?

When you need to pull a simple piece of information out of the XML document without messing around with templates to process the element s that house it, you can use a value-of element to grab what you want with an XPath expression:.

As you can see, the select attribute is an XPath expression that searches for the value of the title within the chapter. With value-of , we can print that value out. Now our file displays something like the results shown in Figure 4. Notice the title bar of the browser window, which now contains the title of the chapter. Part 2. Part 3. In the preceding chapters, we gathered requirements for our XML files, administration tool, and display components.

In this case, we do so because it lowers maintenance costs: we only have to edit the form once to affect the whole site. Notice that the action is set to a file called doSearch. The most important page on the site is the homepage. The header will hold global navigation elements. Like our search widget file, this navigation will be an include file — after all, we want to reuse these elements on other pages of the site.

For the homepage of our site, the navigation menu will contain our search widget and a list of current news items. The appearance of the homepage. Our top navigation will be placed in an include file. Although a detailed look at SimpleXML will have to wait until??? Imagine, for example, that you had this very simple XML document:. Our first task is fairly simple: open the xml directory and find every XML file whose name begins with webcopy :.

This code uses a regular expression to match the required file name pattern. The method returns an array of elements that match the criteria specified; in this case that array will either contain a reference to the webcopy element in the file if the status is live , or it will be empty. The file for our homepage will be called index. This file includes both the common. It then goes on to produce the secondary navigation and content divs navSide and mainContent , respectively.

In this code, we open the file called homepage. The first include is the search widget that we built earlier on. For the most part, our news include file will be very similar in structure to the code we used in navtop. We have the homepage all roughed out. For now, all we have to do is make a copy of index.

An id variable will be passed in the query string, which will correspond to the filename of the XML file that contains the associated content. So the ID webcopy3 will correspond to a file named webcopy3. Otherwise, we could find our script turned against us as a clever hacker submits a value that points to some sensitive file on the system.

For our purposes, a regular expression that verifies that the variable contains an alphanumeric string only numbers and letters will suffice. With the file loaded, we must pull out the values inside for display in the template. For example, we want to use the navigationlabel element for the page title, but if no such element exists we want to fall back on the headline element.

With all this in mind, you should be in a position to understand the complete template at a glance. What does our sample site look like so far? Displaying the CMS project so far. Buy your own copy of the book now, right here at SitePoint. By: Satish Balakrishnan. Dictionary Dictionary Term of the Day. Natural Language Processing. Techopedia Terms. Connect with us. Sign up. Term of the Day. These technologies would require users to install browser plug-ins, and in some cases meant that certain users would be unable to access the content for example, iPhones and iPads don't support Flash.

HTML5 has added support for many new features that will make it possible to do more with HTML, without relying on non-standard proprietary technologies. Skip to main content. Organize page content by adding headings and subheadings to the top of each section of the page. Add an invisible drawing pad to a web page, on which you can add drawings animations, games, and other interactive features using Javascript.