Parameter entities

I have done a lot of work building parameter entitie examples for this course. Most of them do not work reliabily in many environments. So, I have omitted them. I kept a couple of examples that work. They work, but are not very useful.

You should look through this page briefly. Later, if you are working in an enviromnent where they work, you will have some familiarity with them.

Usually, you write the DTD in a seperate file, not in the same file with the XML document. This allows the DTD to be used with many XML document files, all of which conform to the specifications of the same DTD.

When using a parameter entity in a seperate DTD file, not with the XML document, we can say that it is an external parameter entity. An external parameter entiy is not in the same file with the XML document.

An external parameter entiy can be very useful. It can be used within another entity. Its most valuable use is to provide common attributes, which are used in many attribute lists. For example, onFocus, onBlur, and several other attributes are used with many entities in XHTML. The list of common attributes can be written once within an external parameter entity, and then the external parameter entity can be used in many attribute lists.

You code a parameter entity that looks like the following:
<!ENTITY % parameter-name parameter-definition>

When you use a parameter entity, it looks like the following:
%parameter-name;
When you use a parameter entity, the parameter-defintion is substituted into the DTD code at that place.

I have had so much trouble trying to use SYSTEM parameter definitions, that I suggest you ignore this topic. This is a description of how it should work. I have tried it with different wellformed checkers and DTD validators, including, validome.org, codeplot.com, xml copy editor, and firefox. The only thing I got to work is a SYSTEM parameter in an internal DTD, which is of very limited value.

We have been talking about external parameter entities, that are in a DTD that is in a different file than the file containing the XML document. We will continue talking about external parameter entities.

In the last section we coded a parameter entity that looks like the following:
<!ENTITY % parameter-name parameter-definition>
You code the parameter-definition within the ENTITY element. Everything you type following the name, to the closing > is the parameter-definition. The parameter-definition may be several lines of code, before you get to the closing >

It is also possible to use a parameter-definition that is in a different file from the DTD. So we have the XML document in one file, the DTD in a second file, and the parameter-definition in a third file.

If you want to use a parameter-definition that is in a different file within your system, you code:
<!ENTITY % parameter-name SYSTEM URI>
The keyword SYSTEM means the parameter-definition is in a file somewhere in your system. If the file is in the same directory with the DTD, the URI is just the name of the file. If the file is in a different directory from the DTD, the URI will usually be a relative address, such as: ../parameter/my-parameter-definition-file
Where   ..   means go up to the parent directory;   parameter   means then go down into the   parameter   directory; and   my-parameter-definition-file   is the name of the file containing the parameter definition. Everything in that file will become the parameter definition.

The URI within your system is often just the file name within the same directory or the relative address near the current directory, as we have seen. It is also possible to use an absloute address, starting with the root directory of your system and working down through the directory levels to the file. It could even be the URL for another web server used by your organization.

You could even use a file provided by an external organization as your parameter definition. You would code:
<!ENTITY % parameter-name PUBLIC FPI URI>
The FPI is the Formal Public Identifier. The value of the FPI should be - if you just built it yourself. If it is agreed on by an organization, such as a meat packing industry group that does not set Internet standards, the FPI should be +   If it is a standard, use the FPI specified for that standard.

You can write a parameter entity within an internal DTD. ( An internal DTD is one that is written within the XML document.) This is called an internal parameter entity.

You specify the entity as you would with a general entity, Except use a % instead of an &

Once you have created the entity, you can refer to it by using a percent sign, its name, and a closing semicolon. This is similar to a general entity, except it is used within the DTD, not within the XML code itself.

Internal parameter entities cannot be used within any declaration. That means you cannot put them within an ELEMENT or ATTLIST. This limitation makes them more or less useless.

The link takes you to an XML document. In that document the entity   att   is set up by the statement:
  <!ENTITY % att "parameter.dtd">  
Later, the parameter definition is inserted using the statement:   %att;  
You can see this by looking at the source of the file. This works for me in Firefox, but is of little value.

The link takes you to an XML document. In that document the entity   att   is set up by the statement:
  <!ENTITY % att "parameter.dtd" >  
Later, the parameter definition is inserted using the statement:   %att;  
The file   parameter.dtd   contains:
<!ATTLIST name nickname ( Fred | Ike | Larry ) #IMPLIED>
This works for me in Firefox, but is of very little value.