Structure/Schema - Custom or off the shelf?
Marcus Carr
mcarr at allette.com.au
Thu Feb 2 23:18:27 PST 2006
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
More information about the framers
mailing list