DTD vs. XML Schema

AShocka writes "The W3C XML Schema Working Group has released the first public Working Draft of Requirements for XML Schema 1.1. Schemas are technology for specifying and constraining the structure of XML documents. The draft adds functionality and clarifies the XML Schema Recommendation Part 1 and Part 2. The XML Schema Valid FAQ highlights development issues and resources using XML Schema. This article at webmasterbase.com addresses the XML DTDs Vs XML Schema issue. Also see the W3C Conversion Tool from DTD to XML Schema and other XML Schema/DTD Editors."

Comments

Power

[sethadam1]

There's no "vs."

XML Schema are much more flexible and powerful.

There're also about 100 times more difficult and confusing.

Re:Power

[Lulu of the Lotus-Ea]

There certainly is a "vs." involved. There are many good reasons to choose DTDs for a given validation requirement rather than W3C XML Schemas. I address some of those in an IBM developerWorks articles:


Comparing W3C XML Schemas and Document Type Definitions (DTDs)

This is a bit old, but still correct. Not a lot has changed in either spec.

I am currently working on a series of articles on RELAX NG. In most ways, I think RELAX NG really is the best of all worlds. It is more powerful than W3C XML Schemas, while being a natural extension of the semantics of DTDs. Moreover, if you choose to use the compact syntax (non-XML), you get something very easy to read and edit by hand.

David...

Vs.? What is this, another poll?

[r4lv3k]

1. DTD 2. XML Schema 3. CowboyNeal validation (via SOAP over SMTP)

All this hype about XML

[MimsyBoro]

I am a programmer for a commercial company (yes I like to make money, and I program on WinTel). I year ago we had the XML craze we converted all our internal protocols to XML. I discovered that XML was just a lot of hype about nothing. There is nothing self-describing about it. Or maybe there is, just like the section names in an INI file describe the keys in them...
On the other hand the one thing that I did find XML useful for is easy parsing. If you use XML to develop a lower level protocol you end up with bloated 10k messages. But for high-level protocols or for configuration files it's great for only one reason: There are lots of ready-made tools. If you want to parse XML in Windows just load the IXMLDocument interface and it works at lightening speed. If you want to parse the messages in a web-browser through together a quick DOM parser or even use the build in DOM one! If you want to parse XML in PERL or C/C++ there are great libs. The only reason XML is good is because all the hype got people developing very neat tools. In one of my latest projects that needs to pass information between two programs written in different languages a used a Home-Made SOAP and designed a base class the persists using XML. I developed it in both langauges in under an hour!
So although it wastes bandwidth and there really isn't anything neat about it, it is comfortable I'll give it that.

Re:All this hype about XML

[sporty]

I year ago we had the XML craze we converted all our internal protocols to XML. I discovered that XML was just a lot of hype about nothing. There is nothing self-describing about it. Or maybe there is, just like the section names in an INI file describe the keys in them...

Great thing about XML, is if you need to convert your communications, you can write XSLT against it to convert it while you convert your XML source.. easily. For instance, one vendor I worked with decided that the old protocol didn't work well anymore, and a ne one would be better. Forget the reasons for the change, good or bad.

I plopped an XSLT processor in front of it. Took minutes to implement. In the mean time, I was able to properly rewrite the XML producing code. So I had some flexibility in terms of patching the protocol quickly, while taking the weeks I needed to fix things right.

As for self describing, what is more self describing than HTML? You see a bold and italics tag around an element, you can easily figure out what style the text would be in. Yes, I know about CSS, but the point is, XML IS descriptive, so long as you use good names. Naming elements a, b and c is just developer fault.

If you use XML to develop a lower level protocol you end up with bloated 10k messages.

If in today's age of gigabit ethernet and cheap parts, you really really need to squeeze that extra bit through, compress the line. Seriously. Simplest case, is using ssh. Hell, it auth's AND encrypts. If you are worried about anonymous access, there are other tools.

Re:All this hype about XML

[plierhead]

I discovered that XML was just a lot of hype about nothing.

Amen to that. Sad to say, but certain parts of the IT industry (and in particular, anything to with one computer (or piece of code) magically talking to another one owned by a different organization) are constantly buying into the bogus claims of snakeoil salesman with silver bullet technologies. XML is merely the latest in a long line.

The only new things about XML, IMHO, are that is has spawned more sub-specifications than any previous pretender to the crown.

Anyone remember CORBA ? Or any of the other zillions of RPC-type mechanisms that people have jumped on the bandwagon of ?

I'm not blaiming the people who push these agendas. I too would love to spend my weekends sunning on the beaches of exotic European tourist destinations and chugging beers on my expense account. The price of sitting through a ferw stiflingly boring and pointless standards meetings seems a small price to pay. All large IT companies employ 2 or 3 people whose job it is to front up to these meetings. Typically these people are articulate and highly versed ex-programmers but architecurally challenged and with little understanding of the real nature of building complex IT systems.

Ultimately, these RPC mechanisms all end up as nothing - or rather, as only perhaps 1% of the eventual solution.

All that XML is, is an easy-to-parse, text based data transfer mechanism. And as the parent posting says, there are some nice tools around for it. Big deal. Probably you'd be silly to use anything else if designing a data transfer. But is it ever going to change the world ? Or even rock it a little ? No.

Re:All this hype about XML

[ttfkam]

Yup, I remember CORBA. It's still used. In fact, it can be used with XML. CORBA provides the interfaces for programmatic logic. There is nothing really required to know about how the ORBs communicate with one another. If an ORB decides that its transport mechanism is XML, so be it.

As for SOAP and XML-RPC, what's so hard about compressing it before sending the message? The whole point about XML is that you don't need to write a new parser. You don't need to write a new broadcaster. Your project is about getting a task done, not micromanaging implementation details.

If (and only if) your higher level API/transport is insufficient for the task do you roll your sleeves up and dig in. Do you write everything in assembly? Why not? It would be faster than whatever language you are using now. The reason you don't is that you have better things to do with your time. The goal is important, not the tool. Everyone has standardized on and is optimizing this one particular tool and it works well. So many people have done work so that you don't have to.

Will it change the world? Of course not. It's just a markup language. Will any other computing tool change the world? Of course not. The end users have never cared how you got to the solution. They cared only if you got to the solution faster than the other guy.

Re:All this hype about XML

[sporty]

That's funny, I just looked at the man page for gzip.

Gzip uses the Lempel-Ziv algorithm used in zip and PKZIP.
The amount of compression obtained depends on the size of
the input and the distribution of common substrings. Typ-
ically, text such as source code or English is reduced by
60-70%. Compression is generally much better than that
achieved by LZW (as used in compress), Huffman coding (as
used in pack), or adaptive Huffman coding (compact).

Mind you, XML is highly repeditive in it's tag use on long documents. Long as in multiple records, not necessarily byte length.

Now let's take a larger file, 'cause after all, since modem users can download 5k html really quick. I've taken the soap distribution from apache (or was it sun) and took all the xml files in there and concatonated them together. 22k XML file. Not huge, but big enough for this example.

Here's my findings:

[caligraphy:~] spencerp% ls -al o.xml
-rw-r--r-- 1 spencerp staff 22118 Jan 23 21:21 o.xml
[caligraphy:~] spencerp% gzip o.xml
[caligraphy:~] spencerp% ls -al o.xml.gz
-rw-r--r-- 1 spencerp staff 3021 Jan 23 21:21 o.xml.gz
[caligraphy:~] spencerp% gzip -l o.xml.gz
compressed uncompr. ratio uncompressed_name
3021 22118 86.4% o.xml

Not bad for taking non repeditive text, with random xml schemas and getting 86.4%. Now imagine a larger one with a consistent schema. Compression goes even higher. Granted, it will be slightly larger than a binary. But even a 100meg file can be moved across a 100megabit network in 5 minutes time. And THAT is a lot of data.

Btw, there is a falacy with your math. If I get 50% compression of an XML file, which could have been implemented in binary format, it doesn't mean the binary format would be 49 times smaller.

Re:One is derided, one is end-of-life'd

[mir]

I think James Clarke's RELAX NG and W3C XML Schema is the best description (if slightly biased ;--) of the relative strength of the 2 technologies. Note that James Clarke also just released a new version of Trang , a tool that does conversions between Relax NG, Schemas and DTDs.

Re:Who needs XML when you got PXML?

[Anonymous Coward]

Better yet, use S-Expressions.
There are tons of parsers available.
markup is simple:
(this_is_the_tag
this is all data
(except_this_is_a_nested_tag with still more data))

Even better still, there are customizable parsers available that can treat these S-Expression as data OR interpret them as program OR a combination of both. One such parser is called "Lisp". Once again, several implementations are available.
Note that things like S-Expressions and Lisp have only been around for 40 years so you might want to give these technologies some time to mature.

Not really

[Codex The Sloth]

This approach to interfaces allows systems to interchange messages without exact version consistency, and without requiring a tight congruence of the applications. It allows a system to "tell what it knows" and another system to "read what it needs" without further ado.

Unfortunately, the use of schemas goes against this idea. It is IMHO a more old fashioned approach of rigidly constraining the messages to an exact specification. This can make interfaces far less robust and flexible, and increase the amount of work.


If your talking about using XML for data messaging not using schemas is just lazy. XML Schema allows optional elements and attributes and/or default values. So if it isn't required, then just make it optional. If you want multiversion interfaces, you have a different XMLSchema for each version. Then each side knows explicitly what the messaging protocol is.

While it's probably true that things mostly kinda work if the versions don't match, you shouldn't be relying on this. There's lots of software out there that does this but that doesn't mean it's the ideal.

If your using XML for markup of documents, schemas are somewhat less useful since the underlying semantics of the tags is usually more important.

The hell I won't

[ttfkam]

Trimming bloat like namespaces and comments? Are you nuts?

How do you embed MathML in another document (like XHTML)? Currently it's with namespaces. How do you propose to do that without namespaces? Just the prefixes? What happens when two different markups use the same prefix? Wups! You're screwed!

No comments? This is supposed to make a better alternative to XML? It won't help readability, and it certainly isn't a major bottleneck during parsing.

Don't want the "bloat" of namespaces and comments? Wait for it... Wait for it... Don't use namespaces and comments in your documents! Wow! What a concept!

Maybe no Unicode in PXML hunh? So much for interoperability for any kind of data. You don't ever want your pet project used in East Asia (or Russia or Greece or most other places in the world) do you? Unicode too bloated? Why not just use ISO-8859-15 (basically ASCII w/ a Euro character -- which incidentally a Euro character isn't available in ASCII)? Oh wait! That's right. You don't want to allow processing instructions, which in XML tell you what encoding is used.

What happens if you want to change some of the basic syntax of PXML? Because you've nuked processing instructions, you can't specify a markup version like you can in XML.

Yes, yes. We've all seen your little pet project. I hope it was just a class assignment.

XML Schemas aren't just for validation

[Osty]

I can't believe nobody's mentioned this yet. Microsoft has a tool that will do several things:

• Generate an XML Schema from an XDR or XML file.
• Generate source code (C#, VB, or JScript) from an XSD file (XML Schema file).
• Generate XML Schemas for one or more types in a given assembly file.

This makes writing your XSD almost trivial. The code-generation capabilities are very powerful, as well, as you can generate runtime classes for serialization/deserialization or classes derived from DataSet so you can treat XML files like any other database, etc. It's very useful if you're doing any .NET framework programming.

I'd be very surprised if there weren't other tools out there doing similar things. I simply mentioned xsd.exe because that's what I'm familiar with.

Re:Validating with XML Schemas

[VP]

This is a misunderstanding of the way schema validation is supposed to work. Schemas have what is called "location hints" which should be used in case you have never before encountered a particular namespace. The key word, however, is "hints" - i.e. you should never have to remotly obtain a schema if you don't need to.

In most cases, if you are doing schema validation, you already know whta schema you can expect, so they should be not only locally available, but also cached in memory...

As for the ..."master" XSD schema... you never ever have to get it remotely - the parser should be implementing it already...

XML is Great of Content Syndication and much more

[valmont]

I notice that this topic is generating many comments from hard-core backend programmers who mainly focus on inter-application messaging and various equivalents of remote procedure calls.

In my experience, many benefits of XML come when dealing with the presentation layers of many application architectures, with the ability to repurpose syndicated data at wil, here are a few examples:

• RSS which defines an easy standard for any site to provide "News" in a well-defined XML Format. This allows developers to write software to aggregate news from different sites into one convenient interface, sites to exchange news headlines with eachother.
• Google Web APIs which allow developers to create their own custom google-powered search site with their own look and feel by simply proxying a user's search query to the google server which returns search results in XML data which can subsequently be transformed in HTML before being sent back to the user via various processes such as an XSLT transformation.
• Amazon Web API, similar in principle to the above Google API, allows developers to enhance their sites by allowing their users to search for Amazon products without having to go the Amazon site itself. One interesting side-effect of such API is that an Amazon competitor, say Barnes and Noble, could offer a similar API to their own site. Now I could allow my users to use my service to search for books and offer them results and price comparisons from both Amazon and Barnes and Noble

Effective use of XML and XSLT allows you to easily aggregate informational data from one or multiple sources and "repurpose" for an infinite variety of business and technological goals.

One of the main benefits of XML is that it offers and effective, textual representation of "scructured data", that can be conveniently accessed and manipulated according to a slew of various surrounding standards such as XPath, DOM, XSLT, namespaces.

Use both!

[Capsaicin]

This is true, but DTD's are more human readable IMHO.

Absolutely. All the possible attributes, and kids of any element are there in one (OK, two) place(s) and you can garner the information about any element in a matter of seconds. With XML Schema you have to keep track of the levels of nesting and rifle through a series of name/value pairs to get the same information. It is in its greater expressiveness that the advantage of XSD is seen to lie. And there might be applications where this expressiveness necessitates the use of XSD.

However, XML Schema, has besides this expressivenss, one other great advantage. It is XML. As such it can be processed with the same XML tools one uses elsewhere with an XML application.

As an example, in one application, I take a DTD, translate it into XSD, and then run an XSL stylesheet over the XSD file to generate some base code used in my application. In this way I can ensure that my code will automatically be changed to reflect any minor changes made to my Schema.

So while I continue to write DTDs, I look on XML Schema as a way to translate, and bring my DTD into the XML universe, with all its attendant advantages.