OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index]
Re: [xml-dev] Use DTDs!

Roger, you often posit situations that are
contrasting black-and-white with no middle ground
or few or no alternatives.  I find this
misleading and I worry about the impression on readers who don't know better.

For all the points you cite, my decision to use
RELAX-NG for the information structure and DTD
entities for the content structure holds equally
as well for me, but the semantics of ISO/IEC
19757-2 RELAX-NG validation are far more
expressive than those found in DTD
validation.  Maybe not for your example
situation, but the co-occurrence constraints and
a number of other powerful features of RELAX-NG
can model the constraints of a document in such a
way that unburdens downstream applications.

T:\ftemp>type aircraft.xml
            <model>Boeing 747</model>
            <altitude units="feet">12000</altitude>

T:\ftemp>type aircraft.rnc
start = element aircraft
          { element model
                    { text },
            element altitude
                    { attribute units { "feet" | "meters" },
                    text }

T:\ftemp>jing -c aircraft.rnc aircraft.xml


Examples in RELAX-NG of linking an attribute's
presence or value to allowed element content, and
offering mutually-exclusive attributes, guide the
user to creating source XML information that
truly expresses relationships without downstream
processing having to do its own validation of
constraints that cannot be expressed by DTDs.

The XML processor interprets the entity structure
and delivers the infoset to the application ...
for modeling the document constraints I advise my
customers to consider RELAX-NG and its use has served them well.

. . . . . . . . Ken

At 2016-04-29 17:40 +0000, Costello, Roger L. wrote:
Hi Folks,

Heavy-duty validation is not always needed.
Sometimes all that is needed is to verify that
XML instances are using the right set of tags.

Let me state it stronger: I have observed that
“verifying that XML instances are using the
right set of tags” is how most developers view
XML validation. Their XML Schemas are merely
thinly veiled versions of DTDs. Developers opt
to perform the heavy duty data checking in Java code and/or in a database.

For many (most?) situations use DTDs, not XML Schemas. Here’s why:

1. Less tools needed: Only one tool is needed –
a validating XML processor. Conversely, if you
use XML Schemas for validation, you need two
tools – an XML processor plus an XML Schema
validator. The less tools needed, the better.

2. Less to read: If you stick to DTDs, you only
have to read the XML specification, which is
about 36 pages long. If you use XML Schemas, you
have to read XML Schema Part 1, which is around
350 pages and XML Schema Part 2, which is around 100 pages.

3. Less complexity: DTDs are several orders of
magnitude simpler than XML Schemas.

4. Less verbosity: The DTD syntax is streamlined
and efficient (kind of analogous to XPath in
terms of being streamlined and efficient). The
XML Schema syntax, on the other hand, is bloated and inefficient.

5. Robust validating tools: The capability of
validating against a DTD has been around a long
time, the tools are rock-solid. Comparatively,
the capability of validating against an XML
Schema has been around a short time, the tools are less rock-solid.

6. Inexpensive: Validating XML processors are
either free or inexpensive. True, there are some
free XML Schema validators, but some of the most
popular XML Schema validators are quite pricy.

7. Suited to Architectural Forms: [Norman Gray
wrote:] a zeroth-order description of
Architectural Forms is that they were a
transformation of a document, specified within
one or other DTD rather than in a separate
transformation language. This did not make for
luminous syntax.  No.  But it was I think the
conceptually Right Place for this
transformation, it meant that that
transformation could be implemented efficiently within the parser, and
it meant that it was natural to conceive of the
transformation as 'pulling' the AF instance
document out of the DTD instance document, which is a Really Useful Idea.

8. Infoset happiness: [John Cowan wrote:] There
are a number of XML DTD features which affect
the infoset returned by a compliant parser.  If
they are in the internal subset, the parser MUST
respect them; if they are in the external
subset, then any parser that reads the external
subset likewise MUST respect them.

Example: Validate that the following XML
instance document uses this set of tags:
aircraft is the root element, within it are
model (which contains data) and altitude (which
contains data and has an attribute, units, whose
value is feet or meters). The following DTD is very adequate.

DTDs – live long and prosper!


<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE aircraft PUBLIC "-//example//aircraft//EN" "aircraft.dtd" >
            <model>Boeing 747</model>
            <altitude units="feet">12000</altitude>

<!ELEMENT aircraft (model, altitude)>

<!ELEMENT model (#PCDATA)>

<!ELEMENT altitude (#PCDATA)>

<!ATTLIST altitude
             units (feet|meters) #REQUIRED>

Check our site for free XML, XSLT, XSL-FO and UBL developer resources |
Streaming hands-on XSLT/XPath 2 training @US$45: http://goo.gl/Dd9qBK |
Crane Softwrights Ltd. _ _ _ _ _ _ http://www.CraneSoftwrights.com/x/ |
G Ken Holman _ _ _ _ _ _ _ _ _ _ mailto:gkholman@CraneSoftwrights.com |
Google+ blog _ _ _ _ _ http://plus.google.com/+GKenHolman-Crane/posts |
Legal business disclaimers: _ _ http://www.CraneSoftwrights.com/legal |

This email has been checked for viruses by Avast antivirus software.

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index]

News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 1993-2007 XML.org. This site is hosted by OASIS