As Jeff has written lately we here at Alagad have been working on an Object Management System (OMS) for one of our clients. In the OMS we use XML to to define the database, objects, and (hopefully sometime soon) the views. While I am not that well versed in the intricacies of OO development, I am very well versed in tagged meta-languages. Specifically SGML. I know, it’s a blast from the past but almost everything we do is based on it so I figured I should mention it.
During my career I have written hundreds of DTD’s and the accompanying output specs. I have taught classes on document analysis and DTD authoring. I mention this because my first thought was to use DTD for the XML in our OMS. Clearly it was the most expedient way of defining the XML for me and it gave the opportunity to get back to some of my roots. I had forgotten how much I enjoy analyzing and defining data structures.
Well, for the first portion of the OMS DTD has worked just fine. As you’ve probably guessed, we are now running into some of DTD’s limitations. Custom data typing, namespace and compatibility with other XML technologies are amongst the limitations to which I refer. While most of these limitations can be overcome with creative element, entity, and attribute declarations, the complexity and usability of the DTD starts to make the XML suffer.
Identifying and describing the XML for the objects (DAO, IBO, AdminService, etc…) was relatively easy.There are only so many different elements to define. As we move forward and begin trying to define views, the complexity level of the DTD skyrockets. Trying define every possible, allowable and desirable aspect of a view is daunting. We have already had several instances where we have had to deal with limitations that have forced us to alter our approach. Elements can become many and deeply nested and attribute lists can become very long. These factors contribute to making the XML that much more difficult to write and read.
Enter Schema. Yes, I know it has been around for a while but I have never had a reason to use it. Or, at the very least, not a good enough reason. I think I may now have that reason but making the jump will require a bit of learning and lot of time spent writing… I think.
I have read all the usual “DTD vs. Schema” articles, posts, etc… and I think we need to move in the Schema direction. I am looking for feedback from y’all with compelling arguments for or against this proposition. Is the complexity/learning curve of Schema outweighed by the potential complexity/limitations of DTD in this argument? Should we even bring RELAX NG into the conversation?
Help me out here folks. I look forward to your input.
Until next time.
DougHughes.net 
Comments on: "Scheming on Schema -or- The Great DTD Debate" (4)
The last time I worked on an XML project, I had little experience with either DTDs or XSDs. It didn’t take long to run into DTD limitations, and I was able to learn enough about Schema to put together an XSD that was sufficient for our needs.
If you have a ton of experience with DTDs, I’d recommend Schema anyway, if only as an opportunity for you to see what more you could do in it … if you can develop a proportion skill with Schema, that should be enough to address any other XML needs you’d develop.
LikeLike
Schemas rule… but they are as much fun as learning design patterns. Suggestion… code more and use a crutch (as some refer to helper tools for OO dev.) Altova has some great solutions… but they aren’t free. If your looking for free schema tools there is always notepad. 🙂
IMO… schema = what do you want to do, DTD = if this is all you need.
So perhaps your previous business decision was a good one from a business perspective and it’s just time to transition for business changes. 🙂
LikeLike
I use xsd’s all the way for my stuff and find they’re a better fit for what I do that DTD’s (too limiting) or RelaxNG (not as popular and didn’t fit as well for our use case).
Just remember that for a non trivial system you’ll probably need some kind of constraint checking language on top of your xsd’s – you can’t describe complex inter-relational dependencies directly in xsd’s, but they’re great for the first level of validity checking of xml docs.
LikeLike
http://concealer.mybrute.com
Check out this cool mini fighting game
LikeLike