Home > Articles > Web Services > XML

  • Print
  • + Share This

Getting Down to Cases

In this chapter you've examined the XML DTD in detail. You should understand how they're constructed in whole and in part. Every declaration with the DTD has an exact syntax with rules that must be followed, and the XML macro facility—parameter entities—has an even stricter set of rules, which limit its use to the external DTD subset.

However, the whole issue of defining and using DTDs is a thorny one in XML. Most of the really useful things you might like to do, such as including graphical illustrations in a document, or defining IDs within a document so stable references to particular locations can be pointed to using XPointer and XPath, require that the DTD be parsed by a validating parser.

Validating parsers have problems of their own. Because they require that the entire document be read in completely before displaying any part, they slow down page loading to the point that it's irritating to look at unless the document is sitting on the hard drive of the machine you're using to view it. Because the DTD itself may not be available on demand, or might require waiting through a lengthy dialup sequence, load time can be expected to be highly variable on that account alone.

Certain XML browsers may try to finesse the problem by incorporating knowledge of particular DTDs within their code, but this raises the issue of latency when and if a DTD changes for any reason. Although DTDs should probably be invariant over geologic time, there's no way to ensure that this is so rather than the goodwill of the author. The possibility of "validating" against an incorrect local copy of the DTD then exists for any such scheme to improve document load time by hiding knowledge in the browser.

  • + Share This
  • 🔖 Save To Your Account

Related Resources

There are currently no related titles. Please check back later.