XML
  Home arrow XML arrow Page 2 - 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 
IBM Rational Software Development Conference
 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 - DTD Who?
    (Page 2 of 8 )

    Let's start with the basics: what's a DTD when it's home, and why do you care?

    The first part of the question is easy enough to answer. A DTD, or document type definition, is a lot like a blueprint. Unlike most blueprints, however, it doesn't tell you where the kitchen goes or how the capsule containing the plutonium is to be wired up. Nope, this blueprint is a lot more boring - it tells you exactly how an XML document should be structured, complete with lists of allowed values, permitted element and attribute names, and predefined entities.

    DTDs are essential when managing a large number of XML documents, as they immediately make it possible to apply a standard set of rules to different documents and thereby demand conformance to a common standard. However, for smaller, simpler documents, a DTD can often be overkill, adding substantially to download and processing time.

    Most XML documents start out as well-formed data - they meet the basic syntactical rules described in the XML specification, and are correctly structured (no overlapping, badly-nested elements or illegal values). However, an XML document which additionally meets all the rules, conditions and structural guidelines laid down in a DTD qualifies for the far cooler "valid" status. Think of it like a free airline upgrade from business to first...except, of course, without the complimentary drinks.

    Why do you need to know about this? Well, you don't.

    If your day job involves carrying out covert operations for an unnamed intelligence agency or building houses, you'd be better off studying the other sort of blueprint. If, on the other hand, your job involves developing and using XML applications and data, you need to have at least a working knowledge of how DTDs are constructed, so that you can roll your own whenever required.{mospagebreak title=How's The Weather Up There?} In order to illustrate how DTDs work, consider this simple XML document:

    <?xml version="1.0"?> <weather> <city>New York</city> <high>26</high> <low>18</low> <forecast>rain</forecast> </weather>
    As of now, this file is merely well-formed - it hasn't yet been compared to a DTD and declared valid. In order to perform this comparison, I need to link it to a DTD - which I can do by adding a document type declaration referencing the DTD.

    <?xml version="1.0"?> <!DOCTYPE weather SYSTEM "http://www.somedomain.com/weather.dtd"> <weather> <city>New York</city> <high>26</high> <low>18</low> <forecast>rain</forecast> </weather>
    As a result of this addition, the document would be validated against the DTD located at http://www.somedomain.com/weather.dtd

    Let's see what this DTD looks like:

    <!ELEMENT weather (city, high, low, forecast)> <!ELEMENT city (#PCDATA)> <!ELEMENT high (#PCDATA)> <!ELEMENT low (#PCDATA)> <!ELEMENT forecast (#PCDATA)>
    To the untrained eye - gibberish. But give it a couple of minutes...

    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 3 hosted by Hostway