What do you think the following DTD snippet would imply?

<!ELEMENT contact (name, email+)>
<!ELEMENT name (#PCDATA)>
<!ELEMENT email (#PCDATA)>

It would mean that a "contact" element could have a "name" element followed by one or more "email" elements. Thus, the following XML would be valid

What about the following?

Well that would be invalid because in the DTD, we have specified the "+" which is indicated that "email" element must appear "at least one". To allow for "zero or more" occurrences, you must use a "*" instead, such as:

<!ELEMENT contact (name, email*)>
<!ELEMENT name (#PCDATA)>
<!ELEMENT email (#PCDATA)>

In this case, we expect to see XML along the lines of

Alternatively, the following code would be valid:

Notice that since we simply listed the children of "contact" as a space delimited list, we do not specify any order in which the children should appear. If we wish to have the elements appear in order, we must use a comma to separate the list. Like the folllowing:

Then the following XML would be valid

	<contact>
		<name>Sam Duncan</name> <email>sam@technomusic.org</email>
	</contact>

But the following XML would be invalid because the "email" element would not be allowed to precede the "name" element.

	<contact>
		<email>sam@technomusic.org</email> <name>Sam Duncan</name>
	</contact>

]]>

	<?xml version = "1.0" encoding="UTF-8" standalone = "yes"?> <!DOCTYPE contacts [ <!ELEMENT contacts ANY> <!ELEMENT contact (name | email | phone | #PCDATA)*> <!ELEMENT name (#PCDATA)> <!ELEMENT email (#PCDATA)> <!ELEMENT phone (#PCDATA)> ]> <contacts>
		<contact>
			<name>Sam Duncan</name> <email>sam@technomusic.org</email> <phone>2648 4848 XYZ</phone> Blah blah blah
		</contact>
	</contacts>

]]><!ELEMENT hr EMPTY> <!ELEMENT hr EMPTY>

Then in your XML code, you should have an element <hr/>

Note that in the example above, if no TYPE is specified the default value "chicken" is assumed.

• ID represents a unique ID name for the attribute that identifies the element within the context of the document. 
• IDs are much like internal links in plain HTML. 
• For the most part, ID is used primarily by programs or scripting languages that process the document. 

The value for ID must be a valid XML name beginning with a letter and containing alphanumeric characters or the underscore character without any whitespace.

ID is incompatible with the #FIXED keyword but usually appears in conjunction with the #REQUIRED keyword (we'll discuss these later). Of course, while ID is usually #REQUIRED, the reverse is definitely not true.

Also, take care that your ID values are unique within a document!

	<?xml version="1.0" encoding="UTF-8" standalone="yes"?> <!DOCTYPE contacts [ <!ELEMENT contacts ANY> <!ELEMENT contact (name, email)> <!ELEMENT name (#PCDATA)> <!ELEMENT email (#PCDATA)> <!ATTLIST contact contact_num ID #REQUIRED> ]> <contacts>
		<contact contact_num="1">
			<name>Sam Duncan</name> <email>sam@technomusic.org</email>
		</contact>
		<contact contact_num="2">
			<name>John Smith</name> <email>john01@technomusic.org</email>
		</contact>
	</contacts>

The IDREF type allows the value of one attribute to be an element elsewhere in the document provided that the value of the IDREF is the ID value of the referenced element.

	<?xml version="1.0" encoding="UTF-8" standalone="yes"?> <!DOCTYPE contacts [ <!ELEMENT contacts ANY> <!ELEMENT contact (name, email)> <!ELEMENT name (#PCDATA)> <!ELEMENT email (#PCDATA)> <!ATTLIST contact contact_num ID #REQUIRED> <!ATTLIST contact mother IDREF #IMPLIED> ]> <contacts>
		<contact contact_num="2">
			<name>George Pye</name> <email>george@technomusic.org</email>
		</contact>
		<contact contact_num="1" mother="2">
			<name>Nina Pye</name> <email>nina@technomusic.org</email>
		</contact>
	</contacts>

]]> Remember we have talked about entities in XML tutorials? Really, the only way to include unparsed entities as part of the document is through the use of ENTITY type attributes for some elements. Let's us try to show you through example:


	<!ELEMENT illustration (#PCDATA)>
	<!ATTLIST illustration external.artwork ENTITY #IMPLIED>
	<!ENTITY sun.logo SYSTEM "XML in Action: Chapter 2: entity example" NDATA gif>
	<illustration external.artwork="sun.logo"></illustration>

Note: Entities with an NDATA term are unparsed external entities which means that the data contained within these entities may or may not be text. If it is text - this may or may not be XML code. In any case, the parser skips over the details of the contents of such entities. So, there are no constraints upon the type of data that an unparsed entity may contain.

We can name a single entity by declaring the attribute as type ENTITY in the ATTLIST declaration for the element concerned. It is possible to declare the attribute to accept multiple entities by using the type ENTITIES, which works in the same way as the IDREFS type in the section above.

]]> Often we do not need attributes that are treated as character data, refer to other locations within the document and so forth. However, we do want a name value such that might be used for the security level of the document or a language name or code. In XML, we can declare an attribute to be a NMTOKEN. Such as a Java class or a security algorithm. For example:



	<!ATTLIST data authorised_users NMTOKENS #IMPLIED>
		<data security="ON" authorised_users="johN pauL Young"> blah blah blah...
	</data>

We may need  to include several name values with an attribute. If we tried to do that with a NMTOKEN attribute we would get an error. If that's the case, try to use NMTOKENS attribute instead. Since NMTOKENS allows us to include more than one value, of course we can still provide a single value there if we wish.

]]> This type allows an attribute to have a value specified by a notation declared in the DTD in cases which you want certain consequences to follow from the attribute. these are usually used as triggers such as when you want to specify a given player for a given file type.

	<?xml version="1.0" encoding="UTF-8" standalone="yes"?> <!DOCTYPE document [ <!ELEMENT document ANY> <!ELEMENT movies EMPTY> <!ATTLIST movie source ENTITY #REQUIRED> <!ATTLIST movie player NOTATION #REQUIRED> <!ENTITY BladeRunner SYSTEM "dvds/BR/br.mov"> <!NOTATION mp SYSTEM "movPlayer.exe"> ]> <document>
		<movie source="&BladeRunner;" player="mp"/>
	</document>

]]> The default_value can have the following values: 



Value	Explanation
value	The attributes default value
#DEFAULT value	Specifying a default value for an attribute, assures that the attribute will get a value even if the author of the XML document didn't include it. Syntax:  <!ATTLIST element-name attribute-name attribute-type "default-value"> DTD example:  <!ATTLIST payment type CDATA "check"> XML example: <payment type="check">
#REQUIRED	The attribute value must be included in the element. Use a required attribute if you don't have an option for a default value, but still want to force the attribute to be present. Syntax:  <!ATTLIST element-name attribute_name attribute-type #REQUIRED> DTD example:  <!ATTLIST person number CDATA #REQUIRED> XML example: <person number="5677">
#IMPLIED	The attribute does not have to be included. Use an implied attribute if you don't want to force the author to include an attribute, and you don't have an option for a default value.  Syntax: <!ATTLIST element-name attribute-name attribute-type #IMPLIED> DTD example: <!ATTLIST contact fax CDATA #IMPLIED> XML example: <contact fax="555-667788">
#FIXED value	Use a fixed attribute value when you want an attribute to have a fixed value without allowing the author to change it. If an author includes another value, the XML parser will return an error. Syntax: <!ATTLIST element-name attribute-name attribute-type #FIXED "value"> DTD example: <!ATTLIST sender company CDATA #FIXED "Microsoft"> XML example: <sender company="Microsoft">

]]> We have discussed quite extensively upon the concept of entities in XML tutorials. If we recall, both general and parameter entities were used like macros or aliases in XML. The purpose is to save time and effort of retyping the same text over and over again. Also, it is extremely useful when it comes to modifications to data, it needs only happen in one centralised locale to implement global changes.
]]> General entities allow you to create document-wide entities and look something like:



<!ENTITY & name "text that you want to be represented by the entity">

In the real world, you might have something that looked like the following:

<!ENTITY & copyright_text "Copyright © 2000-2001 Vovisoft, all rights reserved">

Entities are referenced using a &entity_name;  such as:

<!ENTITY & tag_names "name | email | phone | address">
<!ELEMENT business_contact (&tag_names; | company_name)>

Make sure you remember the semi-colon at the end of tag_names.

Note: If you wish to specify an entity that has text defined external to the document, simply use the SYSTEM keyword, such as:

<!ENTITY & license_agreement SYSTEM "http://www.mydomain.com/license.xml">

In this case, the XML processor will replace the entity reference with the contents of the document specified.

Remember to define them (entities) first before using them. Thus, the following would be invalid because the tag_names alias is defined after it is used.

<!ELEMENT personal_contact (%tag_names; | birthday)>
<!ELEMENT business_contact (%tag_names; | company_name)>
<!ENTITY &tag_names "name | email | phone | address">

]]> Parameter entities, that can be either internal or external, are only used within the DTD and look something like the following:



<!ENTITY % alias "text to be aliased">

For example, you might have something like....

<!ENTITY % name "text that you want to be represented">

Using Parameter entities, you can shorted the declarations of other elements and attributes such as:

<!ENTITY % tag_names "name | email | phone | address">
<!ELEMENT personal_contact (%tag_names; | birthday)>
<!ELEMENT business_contact (%tag_names; | company_name)>

Parameter Entity declarations must precede any reference to them and must be properly nested.

]]> There are two type of DTDs
• Internal DTD
• External DTD

Internal DTD
Here is an example of declaring internal DTD:

<!DOCTYPE Catalog [ ...internal subset declarations here... ]>

Internal DTDs are very useful such as for simple vocabularies - particularly when testing prototypes of markup.

External DTDs
Here is an example of external DTD:

<!DOCTYPE Catalog SYSTEM "http://vovisoft/dtd/sample.dtd">

External are more flexible in certain respects. However, in some cases, authors might wish to use both an internal DTD and an external DTD. An internal DTD uses to add declarations. When an internal DTD declares some item that was also declared in the exernal DTD, the internal declaration supersedes the external declaration. Thus, care must be taken when using both internal and external DTDs

]]> Throughout this tutorial, we have already alluded to several times on DTD. For simplicity, a DTD can either be included as part of well-formed XML document (where we have standard="yes") or it can be referenced from an external source (standalone="no").

In order to reference an external DTD, both the XML and the DOCTYPE declarations are must change accordingly.

1. The XML Declaration must be changed to reflect the fact that the XML document will not work on its own. That is, it will not be standalone.



<?xml version = "1.0" encoding="UTF-8" standalone = "no"?>

2.You will also need to change the DOCTYPE declaration to add the SYSTEM attribute.


<!DOCTYPE root_element SYSTEM "URL_of_external_dtd">

Such as....

<!DOCTYPE contacts SYSTEM "http://www.mydomain.com/dtds/contacts.dtd">

We can also have the URL may be a relative or absolute file location. For examples:

a. Specifies a dtd file in the same directory as the XML document that references it.

<!DOCTYPE contacts SYSTEM "contacts.dtd">

b. We can reference the same document up one directory and down one into the "dtds" directory. Like the following

<!DOCTYPE contacts SYSTEM "../dtds/contacts.dtd">

Using this method, you can simply cut out the DTD part from your XML document and save it into the separate document called contacts.dtd. Therefore, you have one file with the DTD and one file with the well-formed XML document.

Note: The SYSTEM keyword does more than simply reference to an external DTD, it's primarily used for referencing private DTDs that are shared among the documents of a single author or organization.

 

]]>
• Easily and efficiently be shared by more than one XML document, you can write a DTD once and have multiple documents reference to it.
• Only need to change one  to the central DTD, all documents that rely on the DTD are updated in one fell swoop.
• Save typing time.
]]> As we have discovered above, we could have DTDs as private. However, the DTDs may also be made available to the public by using the PUBLIC keyword. Below is the generic format for referencing a PUBLIC DTD



<!DOCTYPE root_element PUBLIC "dtd_name" "URL_of_external_dtd">

In usage, it would look more like the following:

<!DOCTYPE contacts PUBLIC "contact_dtd" "http://www.mydomain.com/dtds/contacts.dtd">

The names used for DTDs may contain only alphanumeric characters, the space, new line characters, and the following punctuation: - _%$#@()+:=/!*;?. Also, DTD names follow some general standards.

]]> ISO standard DTDs begin with ISO. There are two types:
• Approved non-ISO standard DTDs begin with a plus (+) sign.
• Non approved non-ISO standard DTDs begin with a dash (-).

For example:

<!DOCTYPE contacts PUBLIC "-//Your Name//Contact Data//EN" "http://www.mydomain.com/dtds/contacts.dtd">

Whichever the case, the format is same as above. Where Your Name is the owner of the DTD, Contact Data is the type of document the DTD describes, and EN is the language reference (ISO 639).

]]>