Alan Houser wrote: > I've valued your opinions over the years, but I must take exception to > your assessments of both DITA and DocBook. DITA architect Michael > Priestley (a co-author of the 2001 paper you cited) has more recently > addressed the misconception that DITA is an exchange format, not an > authoring format > (http://groups.yahoo.com/group/dita-users/message/1081). My anecdotal > experience matches Michael's -- that about half of all implementations > use the DITA DTD "out of the box" for content authoring.
Yes, but why? I believe that it's because there's tool support for DITA, not necessarily because it's the best structure for the data. There's nothing magical about the structure of DITA, so why hasn't anyone else been so clever in the last 30 years of structured documents as to stumble across this little beauty of a structure? People use DITA "out of the box" because when coupled with other DITA tools, they find they've got a low entry point to "doing XML". Are they really doing the right thing? My feeling is that if DITA is a replacement for analysis, they may not be. Put another way, what does DITA out of the box give you that XHTML doesn't? > Regarding DocBook -- I acknowledge that it's big, and has a "designed by > committee" feel. However, I've seen too many companies use it > successfully to dismiss it. Having a set of extensible XSLT > transformations is absolutely invaluable -- not for the easy stuff, like > transforming "<title>" to "<h1>", but for the hard stuff, like building > a back-of-the-book index. Try writing that XSLT code from scratch. Use it for turning bytes into hardcopy? No problem. Use it as a corporate data structure used to drive a variety of products? Less likely, I would think. No question though - tools can be handy. I guess my point is that if your structures are so generic as to be supportable by existing tools, are they specific enough for your long-term data requirements? > DocBook's size isn't necessarily the problem it may appear to be. > Authors tend to learn markup languages by example. Their approach is > typically "here's how we mark up a help topic in DocBook" (bottom-up), > as opposed to "which of DocBook's 400 elements do I need to mark up a > help topic?" (top-down). The overall size isn't necessarily the problem, it's the number of choices available in the elements when you're working bottom-up. The examples I provided were footnotes and table entries. I just did a rough count on footnotes and they appear to support something like 55 elements. Call me crazy, but I doubt if 95% of anyone's documents would ever require more than 5 elements in a footnote, so forcing users to sift through the other 50 is wasted effort. Sure you could cut the other 50 elements out of the schema, but I'd rather establish which elements I really *want* to allow in a footnote and then add them. > I would also argue that the "ugly but legal" DocBook constructs you > observed are due to limitations in the expressive capabilities of XML > DTDs, not of DocBook per se. ;-) If DocBook isn't able to be be elegantly represented in XML, to me that points to a problem with DocBook, not with XML. XML isn't perfect by any stretch of the imagination, but it's been judged to be good enough to sweep everything in its path. > I'm not saying "use DITA" or "use DocBook." There's lots of value in > building custom DTDs, and organizations do it successfully all the time. And by the same token, I'm not saying don't use DITA or DocBook - there are good uses for both. I'm just saying that the fact that they exist doesn't necessarily mean that they'll be less work or equally useful to creating a schema from scratch. Sometimes they will, sometimes they won't. > However, many organizations under-estimate the effort required to build > the publishing component (e.g., XSLT transformations) to accompany a > custom DTD. If you have the time and expertise to do this yourself, > great. If not, or if you would prefer to devote this effort elsewhere, > architectures like DITA, DocBook, or Scriptorium's DocFrame, which > include the necessary publishing component, can become much more > appealing than a home-grown alternative. I'd be inclined to contract out the XSLT work and concentrate my efforts on the data structures. Mediocre XSLT applied to data following a well-conceived structure will never give you heartburn the way elegant XSLT run over a sub-optimal data structure will. You can tune XSLT later, but you tend not to get the same luxury with the structure. Once you've started creating data to it, changes to the schema can impact your entire data set. Only yesterday I received email from a list member who had been inspired by this thread to update me with the results of their implementation. This person created their first structured FrameMaker application *because* of the "DocBook-derived monster the users were currently wrestling with". They were happy, and now the learning curve has been overcome from start to finish - they have done the whole process. The next time they take this sort of thing on, it'll be that much easier. -- Regards, Marcus Carr email: mcarr at allette.com.au ___________________________________________________________________ Allette Systems (Australia) www: http://www.allette.com.au ___________________________________________________________________ "Everything should be made as simple as possible, but not simpler." - Einstein
