Slashdot Log In
DTD vs. XML Schema
Posted by
CowboyNeal
on Thu Jan 23, 2003 06:01 PM
from the out-with-the-old-in-with-the-new dept.
from the out-with-the-old-in-with-the-new dept.
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."
This discussion has been archived.
No new comments can be posted.
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
Power (Score:5, Insightful)
XML Schema are much more flexible and powerful.
There're also about 100 times more difficult and confusing.
Re:Power (Score:4, Insightful)
The phrase "difficult and confusing" goes hand-in-hand with any flexible or powerful computer utilities.
Full utilization of XML (and myriad programming languages) takes time.
They call them "languages" for a reason. You can't write a sonnet in French if you have only studied it for a year; and you can't write a full-featured browser suite if you started coding a month ago.
Ironic, no, really... (Score:4, Interesting)
The back-end curmudgeons are right, XML stinks for a universal wire format. But for loosely-coupled, message-based, semantically-rich systems it is hard to beat. And document-oriented systems which don't use XML barely deserve notice any longer.
I gently refer s-expression trolls to paul [prescod.net] and oleg [okmij.org]
Use both! (Score:5, Insightful)
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.
Re:Power (Score:5, Informative)
[ibm.com]
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...
Who needs XML when you got PXML? (Score:2, Informative)
believe me, you won't use XML anymore if you once tried PXML [pault.com]
Re:Who needs XML when you got PXML? (Score:5, Interesting)
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.
Re:Who needs XML when you got PXML? (Score:4, Interesting)
There are tons of parsers available.
How does one specify the character set in some, imagined or real, S-Expression markup? Do these "tons of parsers" support Unicode at least? Where to put processing instructions? Character entities? External entities? "Raw data" sections with markup suppressed? How does one specify the document type identifier? Namespaces? All these things fulfill important tasks for XML to be an universal, yet concise, markup language, and all this can make your dreamt-up S-Expression language as contrived as XML is sometimes perceived to be.Attributes, I presume, are out of our concern? You note that the means for syntactic description of data trees are around for 40 years. Yet there was yearning for something more... handy, or something. Doesn't it give any hint to you?
The hell I won't (Score:5, Insightful)
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.
Who needs PXML when you got HTML? (Score:4, Funny)
believe me, you wont use XML (and those pesky XSLTs) anymore if you once tried HTML [w3.org]
AND (most importantly) in virtually every single web browser that you can find, support for viewing this format over the internet is available and built into the browser itself!
Vs.? What is this, another poll? (Score:4, Funny)
One is derided, one is end-of-life'd (Score:4, Interesting)
While the W3 continues to push Schema, they are also forming working groups for RELAX after pressure from XML luminaries such as James Clark.
Re:One is derided, one is end-of-life'd (Score:5, Informative)
I think James Clarke's RELAX NG and W3C XML Schema [imc.org] 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 [thaiopensource.com] , a tool that does conversions between Relax NG, Schemas and DTDs.
WTF!!!! (Score:3, Funny)
All this hype about XML (Score:4, Insightful)
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 (Score:5, Insightful)
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 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 (Score:5, Informative)
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:All this hype about XML (Score:4, Interesting)
Great thing about Lisp, is if you need to convert your communications, you can write Lisp against it to convert it while you convert your Lisp source.. easily.
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.
I plopped a Lisp processor in front of it. Took minutes to implement. In the mean time, I was able to properly rewrite the Lisp producing code. So I had some flexibility in terms of patching the protocol quickly, while taking the weeks I needed to fix things right.
the point is, XML IS descriptive, so long as you use good names.
the point is, Lisp IS descriptive, so long as you use good names.
If you use XML to develop a lower level protocol you end up with bloated 10k messages.
If you use Lisp S-expressions to develop a lower level protocol you don't end up with bloated 10k messages.
Besides, in Common Lisp [elwoodcorp.com] you'll really appreciate MOP [mini.net] - Meta-Object Protocol. Much better than SOAP.
Trust me, I know well, actively use and actually love both Lisp *AND* XML.
Re:All this hype about XML (Score:5, Insightful)
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 (Score:5, Insightful)
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.
XML is Great of Content Syndication and much more (Score:5, Informative)
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:
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 [w3.org], DOM [w3.org], XSLT [w3.org], namespaces [w3.org].
Re:XML is Great of Content Syndication and much mo (Score:4, Informative)
Well, that's why you'd use HTTPS with certificates, no? And nothing is wrong with the port. If you meant HTTP, then yeah, it's plaintext.
Mind you, I don't have a choice of OS's at work. We use solaris and linux. Now amazon, being a windows shop (i'm guessing), only gives out dll's. Great, now I'm not supported. So fine, we use java. Did you know java class (binaries) are versioned? I'm stuck with 1.3.1 ATM and a 1.4 jdk is in the works. Problem is, some jdk's use one version of the binary while another uses.. another. I always hoped it was a universal format. Sadly let down.
That's why technologies like JAXB and translets are poping up. with JAXB, you can bind particular classes to particular schemas/dtd. It speeds up processing. Translets are just compiled XSLT. Really fast since your xslt can be compiled/interpted once, run anyhwere. Kind of a chain technology. translet->xslt->java->machine language.
And mind you, nothing is more secure about a binary format. It's just obfuscated. Hell, I hacked rengeade bbs's users database format so i can write a user deletion tool. Were they going for security, prolly not. Point is, binary is just obfuscated.
As for your sessoin level security, that's not the job of your data format. Your data format and transport layer should be indepenent. It's why you can do SOAP over HTTP, SMTP/mail and possibly anything else that has a function() like response format. request->response. It's probably why ssh is so great. All it is, is a way of authentication, communication and encryption. You can create ssh tunnels for http as a proxy.
RelaxNG (Score:2, Interesting)
Schemas are often a bad idea (Score:3, Insightful)
On very important use is in creating interfaces between heterogeneous systems. Areadable character set and meaningful tags is very handy for developers. The hierarchical structure is extremely powerful. And, of course, the fact that it is a standard with common tools is invaluable.
However, one useful principle of such interfaces is "if you don't understand it, ignore it." In other words, when you get a message, look for what you want in it and use it. Ignore anything that isn't what you want. XML is ideally suited for this approach - especially if you use path based access rather than DOM tree traversal.
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.
Schema processing may also be promoted to "verify" message integrity before processing. However, it only does so in the most primitive ways. Real world messages, especially in the business world, tend to have integrity rules that go far beyond what can be expressed in anything short of a complex computer program or equivalent declarations.
I am sure there are plenty of places where schemas make sense, but in the areas of commercial message interchange, they take a powerful and flexible construct and hobble it.
Not really (Score:5, Insightful)
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.
If or When? (Score:2, Funny)
Validating with XML Schemas (Score:4, Interesting)
It's occurred to me maybe we are being too diligent in actually validating the schema itself, but I'm wondering what others think?
Re:Validating with XML Schemas (Score:5, Informative)
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
XML Schemas are in XML (Score:4, Informative)
One of the greatest things about XML schemas is that they themselves are well-formed XML documents. This makes it a breeze to parse and create XML Schemas. I've just started using XML Schemas in development for the past few months, and they are fantastic. A huge improvement over both DTD and XDR (Microsoft's temporary schema format until XML Schemas came out).
SDAI (Score:2)
web masterbase.com, hrm... (Score:2)
XML Schemas aren't just for validation (Score:5, Interesting)
I can't believe nobody's mentioned this yet. Microsoft has a tool [microsoft.com] that will do several things:
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
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.
one is pathetic, the other ludicrous (Score:1)
I've been developing with XMl for a half a year now, and I found both validation methods to be really bad
DTD is easy to learn, simple to write, only that you cannot really do what it is supposed to do, that is validate well formedness, it is pathetic, for example, you have cardinality operators that allow you to specify one or more, none or more and optional elements but to constrain element occurances to say 2 to 5 is just too much, the founding fathers never thought about that level of complexity
then you have the silly parsed character data as type definintion, sheesh
Schemas aren't really better either. Most schemas are utterly incomprehensible to humans, it is like the Perl there's more than one way to do it philosphy permeates it, you can do the same schemas in so many different ways that it takes a serious mental effort to understand someone else's schemas
gimme something better folks b/c both of these just suck
Shouldn't that be "schemata"? (Score:3, Funny)
When I was in school, the plural of "schema" was "schemata".
</>
I've already selected "No Karma Bonus". Beyond that I can't mod myself downward.
DTDs (Score:1)
Parsing without a DTD (Score:4, Informative)
The key to robust parsing is deferring the decision as to whether a tag has a closing tag until you've seen enough input to know. You have to read the whole document in, build a tree, then work on the tree, but for anything serious you want to do that anyway.
This parser is in Perl. If anyone would like to take it over and put it on CPAN, let me know.
only partially agree (Score:3, Interesting)
I don't agree with you that schema validation is useless. In many cases the documents are fully processed for business rules much later, but you want acknowledgement that your document has reached correctly and it passes atleast the most basic validation (e.g. dtd or schema validation). XML Schema do wonderful job at that. In our case, we always keep schema validation on new doc types until the system is stable and bug free and then remove validation for efficiency (for internal docs). We have discovered many subtle bugs in system which would have been extremely hard to track by looking at application error but were easier to find by looking at parser errors.
Relax-NG is a Draft ISO Standard (Score:3, Interesting)
It would be somewhat unfortunate if both end up popular, because it will be more work to maintain both sets of tools than either one alone. That's probably what will happen, though, at least in the short term.
Schema, and Here's Why (Score:1)
Schema is not only about document validation, but also about layering a rich and extensible type system into XML. DTD can't touch this.
SOAP actually went down the path of adding types to Schema until the actual Schema team did it, thereby simplifying the SOAP system quite a bit.
I'd be happy... (Score:1)
I'd be happy if we could constrain the use cases for XML. It seems to have solved everything! How about limiting its use to the problem set it solves - and I'm not talking about machine to machine communication. What a bloated pile of bits SOAP is. Imagine wrapping a remote method call in layer-upon-layer of XML tags?
Save the world? Heh.
Bill
no one will read it but... (Score:1, Insightful)
The schema team is aware of these problems and have acknowledged that it is a deep problem with schema, which isn't easily fixed. The author even mentioned he used DTD because he didn't want the weight of schema. One of the most annoying things about schema that I've seen is people try to export database tables as tables for a OO application to use. that makes absolutely no sense and schema in its current form doesn't discourage that kind of usage. Many people in the Java prefer castor for that reason. Perhaps the author needs to research about DTD, Schema, marshalling, unmarshaling a bit further to see how and when they break horribly.
XML and Schemas (Score:2, Interesting)
Uncalled-for XML-RPC flames (Score:2, Insightful)
The real strength you get for free when using XML is that you can use standard parsers and transformers to handle different kinds of data in a uniform manner.
I'll give you an example..
Today I was working on my wxWindows application, and I needed to translate (i18n) a lot of windows, dialogs and menus to a few languages. The resources are specified in XRC which is an XML format.
Within XRC files labels for buttons and other widgets are written in the language they were created in, usually english.
What I did was write an XML catalog file for each language. I then ran an XSLT processor with the XRC files, using the catalogs as plugins with a simple pattern match rule -- and I didn't have to write one single line of customized code to do it.
Though for RPC I'll stick to CORBA with IIOP any day
Check out Relax NG (RNG) (Score:3, Informative)
What's more there's a fantastic tool dtdinst [thaiopensource.com] that converts DTDs into Relax NG. There's also tools to convert back and forth between WXS and RNG. So if I ever need to provide someone with a WXS schema I can just run it off automatically.
Now I'm working on a system using AxKit [axkit.org] to parse out the RNG schema, generate HTML forms for completion, roundtrip the data back to the server, assemble an instance document using DOM and display it using XSLT and CSS. But that's another story. People who don't "get" XML should really check out AxKit.
simon
XML assholes (Score:2, Insightful)
People should realize that XML adoption is a matter of degrees and it is perfectly acceptable to adopt just the concept of a simple markup language. Adoption of XML should NOT necessitate the adoption of XSLT, XHTML, SOAP, and every thing else under the sun that is related to it.
If you have a database system with a protocol for passing messages, then maybe add a new type of XML message with a privately known schema. Don't rip up your system and rewrite it as an XML web service, have it talk only the SQL Server XML services, only use XSLT to transform data, and only XPath for retrieving data.
I'm so fucking sick to death of overarchitects who never actually seem to get the job done on time. (And I'm no XP fan, either, so that's saying a lot!)
Tools availability? (Score:2, Interesting)
And sorry, I have neither the time to write my own Emacs mode nor the money to buy commercial XML tools.
Well, so I keep watching the tools and if they are Schema ready then so am I.
Power is in the standard, not the technolegy (Score:1, Interesting)
Sure, you could do the same things with comma-delimited text files. But are there XSLT processors for comma delimited files? Could you easily transform a comma delimited file into:
1) an HTML file
2) an office 2002 file
3) an open office file
4) a pdf
5) etc.
6) different versions of all of the above that presented the data in a different manner
You could do it, but it wouldn't be easy. The fact that the entire industry has standardized on XML and XML schemas makes many things much simpler than before. That's it.
There is nothing magical about the language except for the fact that it is a standard.
Hello World in XML (Score:1, Insightful)
<text xmlns="urn:iana:xml:ns:cruft-1.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema instance"
xsi:schemaLocation="urn:iana:xml:ns:cruft my_ass.xsd">
<phrase length="11" language="english" subfamily="us" charset="latin-1">
<word length="5" capitalized="yes" propernoun="no">
<letter capital="yes" type="ASCII" bits="8">H</letter>
<letter capital="no" type="ASCII" bits="8">e</letter>
<letter capital="no" type="ASCII" bits="8">l</letter>
<letter capital="no" type="ASCII" bits="8">l</letter>
<letter capital="no" type="ASCII" bits="8">o</letter>
</word>
<space breaking="no" width="normal" type="ASCII" bits="8"></space>
<word length="5" capitalized="yes" propernoun="no">
<letter capital="yes" type="ASCII" bits="8">W</letter>
<letter capital="no" type="ASCII" bits="8">o</letter>
<letter capital="no" type="ASCII" bits="8">r</letter>
<letter capital="no" type="ASCII" bits="8">l</letter>
<letter capital="no" type="ASCII" bits="8">d</letter>
</word>
</phrase>
</text>
DTDs are broken (Score:4, Interesting)
XML Schema is also kinda whacked. It shows all the signs of being a committee specification.
The big problem with schema is that you actually have two type systems going. Element definitions are types for elements. Type definitions are actualy types for types for elements. I saw a hopelessly confused attempt by some UML people to express XML schema in UML, they simply could not understand that there was no way it could ever work. UML has completely different semantics.
There are a bunch of schema proposals that folk have said good things about. Eve keeps telling me I should look at Relax. But for the time being XML schema is going to be the basis for standards in W3C and OASIS.
There might be an opportunity to do a clean up job on XML schema in 4 or 5 years but that will only happen if it is causing real problems.
Re:Blah, blah, blah (Score:2, Funny)
And XHTML really bites. You can tell the w3c doesn't listen.
Re:Yawn. (Score:1, Flamebait)
Re:OT: how do you correctly embed flash (Score:3, Informative)
Yup. Even in XHTML. Check out this article [alistapart.com] on A List Apart for a useful method.
Re:Blah, blah, blah (Score:1, Flamebait)
And, as far as the usefulness of XML, I just found it to add extra overhead. The parsers are cute and all, but it doesn't generally help since you still have to know the strucure of the data. So, between the XML creation, the extra data being transmitted, and the parsing, if I want performance, I'll stick with a binary pipe or a simple comma-delimited stream. XML really isn't a big deal at all. Nothing but hype.
Since when... (Score:3, Insightful)
If it was called it a programming language that would be wrong, but it's certainly a language.
Re:I think we're in acronym hell (Score:2)