Using DTD Entities Like Subroutines

This example demonstrates a readable and easy-to-maintain structure for using DTD entities

As I explained in "Defining Entities in a DTD" (SQL Server XML UPDATE, May 2), a Document Type Definition (DTD) entity is a sort of macro that lets you insert predefined code into a DTD. To define an entity in a DTD document, you use the following syntax:

Place this ENTITY directive at the top of the DTD document and use the word THE_MAGAZINE in place of the corresponding text (in this case, XML UPDATE) wherever this declaration is visible. An entity directive is automatically visible in the body of the DTD and in any XML document that imports that DTD. You don't need to use DTD files or schemas in all cases of XML development, and dropping them often improves the parser's overall performance. However, you can't eliminate the link to the DTD or the schema from XML pages that use these entities. The syntax for DTD entities is powerful because it lets you assign any sort of data to an entity, including plain text and XML data. Furthermore, the parser can read the content of an entity from an external file. &block1;The SYSTEM attribute lets you specify a path to a file whose content is assigned to the specified name. Notice that this path can't be a URL; it needs to be a local path. You can use both absolute and relative paths—for example,&block1;Also, you can insert the entity text anywhere within the same DTD by using the usual entity syntax&entity_name;You use an ampersand character before an entity name and a semicolon after an entity name. You can take advantage of this naming convention by breaking complex DTD documents into smaller pieces, making the whole structure more manageable. You can develop a long document one section at a time, or you can assign each section to a different author and develop the document in separate chunks—for example,&block1;&block2;&block3;Used in this way, entities relate to DTD like subroutines relate to procedural code. Suppose you have an XML document like the following:......:......This example represents an archive that contains a list of customers and products. Each customer and each product has a set of attributes and subnodes. Let's say that this information changes frequently and, worse yet, the information belongs to different departments within your organization. Instead of collecting updated information and refreshing the archive yourself, you can charge people from those departments to provide simple XML documents that you then combine. The archive will look like this:&customers_list;&products_list;This example demonstrates a readable and easy-to-maintain structure that works well in a distributed and corporate environment.