Re: [docbook] Re: Ruminations on the future of DocBook

[Morus Walter <morus.walter@tanto-xipolis.de>]

Norman Walsh writes:
> 
> | I agree that the number of tags could be reduced if done properly.
> | Maybe this makes more sense if we rely on attributes more for
> | providing information about the intended use. For example why have
> | <note>, <important>, <caution>, <warning>, <tip>? Maybe a single tag
> | could have been used with the differences being made with role:
> |
> | <attention role=caution> <para>Don't touch that!</para></attention>.
> |
> | The same could have been done with sections: <section>This is just a
> | section</section> or
> | <section role=numbered>This section gets a number.</section>
> |
> | I know that this is water under the bridge (especially considering the
> | need to support existing documents), and my not simplify things, but
> | with my limited experience with DTDs it seems that it may provide some
> | way of simplifying the structure while allowing the complexity to be
> | handled through the use of attributes.
> 
> I don't think that's really making things simpler. It's just moving
> the complexity around. Consider the absurd reduction:
> 
>   <docbook name="book">
>     <docbook name="title">The Book Title</docbook>
>     <docbook name="chpater">
>       ...
> 
> I don't think anyone would argue that that is really simpler.

I think that's missing the point.
The suggestion is, to have two axis (element name, role/class attribute 
value) to determine the meaning of an element instead of one.
What you show is switching completly from one axis to the other.
The suggestion is not simply moving the complexity around but splitting
it.
And I think that makes sense in some cases (e.g. the suggested attention
element).
Consider a general DTD or RelaxNG driven xml editor. It will offer
you a list of elements you might insert at the current position.
The longer the list gets, the more difficult it gets to use it
(e.g. xemacs insert tag list for docbook isn't helpful to me at all in
most contexts).
If you group similar elements by using the same element name and distinguish
them by an attribute, you make this selection easier.

> That
> said, there may be cases where it does make sense to merge things.
> We've already got a proposal to do away with a half dozen or more
> ToC-related elements by replacing them with just two or three.
> 
Of course the basic question is, where this can be done.
Note that such constructs are already used, e.g. for sgmltag which can
be used for all kinds of markup that can be distinguished by it's 
class attribute. And I don't think that it would be better to have
separate elements for each of them.

Morus