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

[Michael Smith <smith@xml-doc.org>]

Paul Grosso <pgrosso@arbortext.com> writes:

> At 20:42 2002 09 06 +0900, Michael Smith wrote:
> >Anyway, about the question at the end of number 3 above -- But what will
> >that do to interchange? -- It seems like interchange isn't an issue if
> >
> >  * the customized DTDs are strict subsets of the complete DTD
> >
> >  * and users/user communities treat their customized DTDs as "authoring
> >    DTDs" and continue to use the full DTD for validation (that is,
> >    don't expect that DTDs that others interchange with their community
> >    will validate against their custom authoring-DTD subset)
> 
> But that leads me to conclude you don't really want to change/subset 
> the DTD, you just want some way to reduce the set a given author has
> to understand/work with.  And I don't see that requirement as being
> addressed at the DTD level, I see it being addressed at the tool level
> and/or document/education level.

I agree with everything you wrote in this thread about the tool level
being the best place to address these ease-of-authoring concerns. I
definitely don't think we should change the DTD for ease-of-authoring
reasons. Specifically, I think:

  * we shouldn't remove elements from the DTD to try to make DocBook
    easier to use
 
  * we shouldn't hesitate to add new, clearly useful elements just
    because of the "DocBook is already too big" concern

That said, I can't imagine any document author or document-authoring
group that would need "full" DocBook DTD as their *authoring DTD*. I
think that any person or group concerned about ease of use should as
their authoring DTD be using a subset of DocBook that provides just
the elements they need to author the types of documents they produce.

And because a lot of people/groups/communities produce similar types
of documents, I was thinking it might be worthwhile (to the extent
that it's possible) for the TC to produce some subsets designed to
meet the needs of some specific, identifiable, communities -- a
subset, say for those that want to use DocBook for online help
authoring, and another for those the want to write a lot of documents
that require some kind of math markup.

But I'm not sure how practical it would be to try to do that, because
in trying to think of identifiable groups with common authoring needs,
it's hard to come up with any group within which authoring needs
woudn't vary widely. Online help, for example, is written for a wide
range purposes by groups with some varied needs. So it might be very
difficult to produce a "help authoring" DocBook subset that didn't
leave out some elements that some help-authoring group would need.

I think we've already seen this with Simplified DocBook -- many people
who try using it often end up finding out that it omits some elements
that they really need for authoring the kinds of documents they
create. That doesn't mean it's not a really useful subset -- it just
illustrates that it's really hard for the TC to produce a subset or
subsets to meet common needs.

So even if the TC were able to produce more off-the-shelf subsets,
there would still be a lot of people that would need to tweak those
subsets to meet their needs, or who need totally different subsets.

And though I don't think that ease-of-authoring concerns should drive
us to make big changes to the DTD, I think there is the other really
important ease-of-use concern that's also been discussed in this
thread: ease of customization (or "ease of subsetting").

So I think it is useful to look at how the modularization/
parameterization scheme can be refined to make it easier to
customize/subset the DTD -- to make it more modular. (And we've
already had a standing RFE for some time requesting and enhancement to
the current parameterization scheme.)

That said, I think myself that:

  * DocBook is already highly modular

  * the modularization/parameterization scheme is very well designed

  * for most part, the difficulties that people run into in trying to
    customize DocBook are simply DTD-customization difficulties, not
    necessarily DocBook-customization difficulties. What I mean is, I
    think they are difficulties that they'd run into in trying to
    customize any large DTD, not difficulties unique to DocBook

But I also think we can definitely make some improvements to the
current parameterization scheme, and that these improvements should
help to make it easier for people to customize/subset the DTD. I just
think we need to be very careful about what kinds of changes we make;
so to the extent that it's possible, I think:

  * an evolutionary refinement might be better than a complete
    refactoring

  * if we went with a complete refactoring, I'd want to be sure it
    just didn't introduce a different set of customization challenges

  --Mike