Future DocBook core/extensions modularization

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

Adam Turoff <ziggy@panix.com> writes:

> On Fri, May 30, 2003 at 09:19:35AM -0400, Stefan Seefeld wrote:
> > Yeah, I would very much like to see a discussion of all the different
> > domains docbook can be applied to ('use cases'), together with domain
> > specific vocabularies. Based on this one may be able to either unify
> > these vocabularies, or create a 'standard' vocabulary with a set of
> > 'profiles'. I think that this is what we are doing informally right now
> > when arguing over task vs. process vs. procedure.

[...]

> So I think the *best* thing DocBook V.next could do would be to identify
> the 100 or so most common structural elements and content models that are
> *universal* and then standardize extensions via namespaces.  Then, as
> someone writing Perl documentation, I could ignore the C/C++/Java centric
> tags on methods and classes and use similar elements that are better suited
> to documenting Perl that most of the world will happily ignore.

I really wonder whether we'll all ever get to any kind of consensus
about the wisdom or viability of doing what you describe, any more than
we ever have in the times we've had long discussions on the list about
it before, like the 'On the size of DocBook' thread last year[1].

  [1] http://sources.redhat.com/ml/docbook/2002-09/threads.html#00054

In that thread, Paul Grosso made a case for the 'size of DocBook' issue
being something that's better dealt with at the tool level, not at the
schema level -

  If users are saying "when I go to enter a tag, my tool shows me
  hundreds of possibilities and that overwhelms me," then my answer is
  to fix this problem at the tool level.  For example, the tool should
  provide a way for the user (or a site administrator) to configure
  things so that only the tags a user expects to use are shown in the
  tag choosing panel.

I wonder if rather than talking again about a "future" or "next
generation" DocBook altered in some way to modularize elements into
core/extended sets, it wouldn't be better to spend time talking about
future or next-generation XML editing applications that are a lot
smarter/configurable in the way the work with sets of element.

In nearly all XML editing applications today, when a user is expected to
make a choice of what markup to use at some point in a document, the
user is just presented with an alphabetized list of every single element
that's valid at that point in the document.

There are a lot of other views that user could or should be presented
with instead: a subset of all the valid elements restricted by frequency
of use (and/or ordered by frequency of use instead of alphabetically).
Or, sets of elements presented in logical groupings instead of
alphabetically. Or presented in some other arbitrary way that users and
user groups could configure to meet their particular needs.

If we had that capability, it would take the task of presenting users
with an element view that meets their specific authoring needs, and put
it where it belongs: in the hands of the implementors and users who have
a clear understanding of what their own specific needs actually are.

I'm not sure that the TC could ever be successful at coming up with some
standard, universal core/extended modularization scheme that would
satisfy very many users.

Attempting it might just create a situation in which we end up having
endless community debates about which elements belong in which modules
(and never coming to any kind of consensus). And at worst, it could end
up making it more difficult, not less, for users to implement
customizations that suit their specific needs (instead of what the TC
guesses their needs might be).

PGP signature