OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

docbook message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Subject: DOCBOOK: Re: On the size of DocBook...

On Fri, Sep 06, 2002 at 05:14:18PM -0400, Norman Walsh wrote:
> / Adam Turoff <ziggy@panix.com> was heard to say:
> | Just for kicks, how difficult would it be to refactor DocBook into
> | a simple core (based on Simplified DocBook, or the moral equivalent),
> | and implement the full DTD as multiple layers of customizations on
> Quite. Hard that is. And it would introduce N! different "DocBooks".
> How easy would that be to explain?

I thought it would be difficult.  How would I explain N! DocBook DTDs?
Well, they're all subsets of the main DocBook DTD.  :-)

How difficult would it be to do that work conceptually, without
going through the exercise creating DTDs, as customization layers
or otherwise?

I suspect it wouldn't be difficult at all.  Most of that work is
already done in TDG.  Identifying the most important core 25-50
elements might be a little tricky, but identifying the 25-50 related
tag groups (<gui...>, <func...>) shouldn't be *that* hard.  :-)

Basically, there are a bunch of people who understand HTML and the
idea behind XML that still find the concepts behind DocBook too
daunting.  Figuring out how to subset DocBook is key.  I think RSS
1.0 is on to something with a simple core and a series of extension
modules (groups of related tags).

> | fail because using DocBook only seems to work for people who have
> | decided that learning how to use the DTD and tools is eventually
> | better than the alternatives, despite the initial pain.
> Would the learning curve for DocBook Core + DocBook Dublin Core +
> DocBook Unix really have a significantly gentler slope? Aren't the
> really hard issues editorial? 

I'd submit that Core + DC + UNIX wouldn't be that difficult to learn.
Most programming language introductions build on concentric layers
of features.  This kind of breakdown is somewhat similar.  Also, it
mimics RSS 1.0 (modulo RDF syntactic sugar): a small, simple core, with
discrete groups of additional elements.

Most of the hard issues *are* editorial.  I don't use authoring
tools, but I'd expect that someone who wants to use a particular
75 elements that describe the content in their document want to
necessarily ignore the other 325 or so that aren't useful.  (Is
this similar to the TEI pizza cutter approach you wanted to avoid?)

> Learning how to do structured authoring
> is hard. I suggest that it's possible that learning how to do
> structured authoring with a big DTD is only incrementally more
> difficult than learning how to do it with a small DTD.

I don't know about that.  Structured authoring with a 14 element DTD
doesn't really compare to structured authoring with a 100 or a 400
element DTD.  People know how to use HTML now, and the good ideas behind
XML are rather well entrenched.


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Powered by eList eXpress LLC