XML
  Home arrow XML arrow Page 4 - The Fundamentals of DTD Design
Dev Shed Forums 
Administration  
Apache  
BrainDump  
DHTML  
Flash  
Java  
JavaScript  
Multimedia  
MySQL  
Oracle  
Perl  
PHP  
Practices  
Python  
Reviews  
Security  
Style-Sheets  
Web Services  
XML  
Zend  
Zope  
Forums Sitemap 
IBM® developerWorks 
Dedicated Servers 
E-Commerce Hosting 
Linux Web Hosting 
Managed Hosting 
Small Business Hosting 
Download TestComplete 
VPS Hosting 
Weekly Newsletter

 
Developer Updates  
Free Website Content 
 RSS  Articles
 RSS  Forums
 RSS  All Feeds
Write For Us Get Paid 
Request Media Kit
Contact Us 
Site Map 
Privacy Policy 
Support 
 USERNAME
 
 PASSWORD
 
 
  >>> SIGN UP!  
  Lost Password? 
XML

The Fundamentals of DTD Design
By: Vikram Vaswani, (c) Melonfire
  • Search For More Articles!
  • Disclaimer
  • Author Terms
  • Rating: 5 stars5 stars5 stars5 stars5 stars / 6
    2001-09-27

    Table of Contents:
  • The Fundamentals of DTD Design
  • DTD Who?
  • Rainy Days
  • Simply Elementary
  • What's The Frequency, Bobby?
  • Turning Up The Heat
  • An Entity In The Attic
  • The Old Popcorn Trick

  • Rate this Article: Poor Best 
      ADD THIS ARTICLE TO:
      Del.ici.ous Digg
      Blink Simpy
      Google Spurl
      Y! MyWeb Furl
    Email Me Similar Content When Posted
    Add Developer Shed Article Feed To Your Site
    Email Article To Friend
    Print Version Of Article
    PDF Version Of Article
     
     
     
    ADVERTISEMENT

    Route your faxes to your email inbox. Private, secure fax numbers available from CallWave. Choose your fax number.

    The Fundamentals of DTD Design - Simply Elementary
    (Page 4 of 8 )

    Now that you know the basics of linking and validating XML data against DTDs, let's focus in on the different components that actually go into a DTD.

    All XML documents consist of some combination of elements, attributes, entities and character data. In case you've forgotten what these are, here are some quick definitions:

    An element, which is the basic unit of XML, consists of textual content (character data), enhanced with descriptive tags.

    <dinosaur>Stegosaurus</dinosaur>
    An attribute is a name-value pair which provides additional descriptive parameters or default values to an element.

    <person sex="male">Spiderman</person>
    An entity is an XML construct, referenced by name, which stores text, images and file references; it is primarily used as a mechanism to store and reuse content which appears in multiple places within an XML document.

    <!ENTITY copyright "This material copyright Melonfire, 2001. All rights reserved.">
    Each of these basic constructs can be defined in a DTD. I'll begin with element declarations, which typically look like this:

    <!ELEMENT elementName (contentType)>
    As an example, consider the "forecast" element from the previous example:

    <!ELEMENT forecast (#PCDATA)>
    In English, this declares an element with name "forecast" and content of the form "parsed character data" (in case you're wondering, this means that the parser will parse the contents of the "forecast" element, automatically processing its child elements and entities).

    The alternative to parsed character data is regular character data, which will be treated as literal text by the parser without any further processing. Here's an example of this type of element declaration:

    <!ELEMENT greeting (#CDATA)>
    In case you don't want to specify a content type, you can escape without making a decision by allowing any content.

    <!ELEMENT address ANY>
    Of course, doing this kinda negates the purpose of having a DTD in the first place...

    If an element contains nested child elements, it's necessary to specify these element names within the declaration. In the following example,

    <?xml version="1.0"?> <book> <author>Stephen King</author> <title>Bag Of Bones</title> <price>$9.99</price> </book>
    the "book" element contains four child elements nested within it - which is why its element declaration in the DTD looks like this:

    <!ELEMENT book (author, title, price)>
    XML also allows for so-called empty elements - essentially, elements which have no content and therefore do not require a closing tag. Such elements are closed by adding a slash (/) to the end of their opening tag. Consider the following XML snippet

    <?xml version="1.0"?> <rule>Every sentence ends with a <period /></rule>
    and then take a look at the corresponding empty element declaration:

    <!ELEMENT period EMPTY>

    More XML Articles
    More By Vikram Vaswani, (c) Melonfire


     

       

    XML ARTICLES

    - How to Set Up Podcasting and Vodcasting
    - Creating an RSS Reader Application
    - Building an RSS File
    - An Introduction to XUL Part 6
    - An Introduction to XUL Part 5
    - An Introduction to XUL Part 4
    - An Introduction to XUL Part 3
    - An Introduction to XUL Part 2
    - An Introduction to XUL Part 1
    - XML Matters: Practical XML Data Design and M...
    - Practical XML Data Design and Manipulation f...
    - SimpleXML
    - XForms Basics, Part 3
    - XForms Basics, Part 2
    - XForms Basics

     
    Accelerating Trading Partner Performance
     
    Competing on Analytics
     
    Cost Effective Scaling with Virtualization and Coyote Point Systems
     
    Five Checkpoints to Implementing IP Telephony
     
    Hosted Email Security: Staying Ahead of New Threats
     




    © 2003-2008 by Developer Shed. All rights reserved. DS Cluster 5 hosted by Hostway