A comparison between the document type definition (DTD) and the XML schema of the Consortium

Source: Internet
Author: User
Tags comparison expression

Many developers are expecting that the XML schema will soon replace the DTD for specifying the XML document type. Although David Mertz believes that the XML schema is a priceless tool in the developer's Treasure house, he is skeptical that the pattern will replace the DTD. This section of the "XML problem" column attempts to compare patterns and DTDs and to illustrate events that occur in the XML Schema world.

Although the World wide XML schema trumps DTDs on many occasions, there are still some areas where DTDs are better than others. Developers are constantly making difficult choices (which are commonplace in the XML world). Let's start by making a distinction between some of these options.

Current situation

The primary reason for using XML as a data representation format is that it is possible to specify the structured requirements of a document: Determine what types of content and child elements can appear in the elements (and in what order and cardinality, etc.). In traditional SGML factions, the presentation of document rules was once a DTD--the formal specification of the Consortium's XML 1.0 proposal did explicitly provide a DTD. However, there are some fairly common constraints that DTDs cannot implement; The main limitation of DTDs is that they lack the expression of data types (you can specify that an element must contain pcdata, but you cannot specify that it must contain such nonnegativeinteger). There is also a secondary problem that the DTD cannot simplify the specification of the cardinality of the child element (it is possible to specify "one or more" child elements succinctly, but even if possible, specifying "seven to 12" can be overly verbose or even completely distorted).

In order to deal with the various limitations of DTDs, some XML users have called for some alternative methods of specifying document rules. It is always possible to programmatically examine the conditions in an XML document, but in essence, it is often more necessary to impose stricter standards, that is, "a document that does not meet a formal set of rules is an invalid document." The XML schema of the consortium is one of the main answers to these requirements (but not the only model available here). Stevenholzner the XML Schema in the XML Insider with the following characteristics, which is worth reiterating here:

Over time, many people have complained to the consortium that DTDs are too complex and require some simpler methods. The consortium heard and appointed a committee to solve the problem, and then came up with a much more complex solution than any previous DTD (p.199). Holzner continues--Almost all XML programmers agree (including myself)--without considering its complexity, the Consortium XML Schema provides many important capabilities and is worth using for many validation rule classes.

At least two basic and conceptual flaws exist in all the "everywhere" goals. The first issue is the candidaterecommendation, which does not contain any entities, that has just ended its review phase on December 15, 2000, and can include parameter entities by extension. The second problem is that, although there are enhanced expressions, there are still many document rules that cannot be represented in XML schemas (some suggest that XSLT be used to enhance the acknowledgment of expressions, but there may be other methods that exist and use it). In other words, the schema cannot perform all the operations that the DTD has long been able to perform, and on the other hand, the schema cannot express the complete set of further rules that people want to impose on the document. More realistically, tools for XML Schemas are not as sophisticated as tools for DTDs (especially in terms of validation, which is the core issue).

The XML document validation rule is still in a state of disarray. Unfortunately, I can't predict what the end result of everything will be. (for summaries that might make sense when using DTDs, see the sidebar "when to use DTDs.) At the same time, let's look at some specific details of what the DTD and XML schemas can say.

A rich type

The real good part of the world of the world's XML schema is the expression of attribute values and the type constraints of element content. And that is precisely where the DTD is weakest. In addition to providing a very rich set of built-in SimpleType, the XML schema allows you to derive new SimpleType using syntax similar to regular expressions. Built-in types include: string, int, float, unsignedlong, Byte, and so on, but they also include types that most programming languages do not have: Timeinstant (that is, date/time), recurring Date (Days of the year), URIreference, language, nonNegativeInteger.

Contact Us

The content source of this page is from Internet, which doesn't represent Alibaba Cloud's opinion; products and services mentioned on that page don't have any relationship with Alibaba Cloud. If the content of the page makes you feel confusing, please write us an email, we will handle the problem within 5 days after receiving your email.

If you find any instances of plagiarism from the community, please send an email to: info-contact@alibabacloud.com and provide relevant evidence. A staff member will contact you within 5 working days.

A Free Trial That Lets You Build Big!

Start building with 50+ products and up to 12 months usage for Elastic Compute Service

  • Sales Support

    1 on 1 presale consultation

  • After-Sales Support

    24/7 Technical Support 6 Free Tickets per Quarter Faster Response

  • Alibaba Cloud offers highly flexible support services tailored to meet your exact needs.