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] | [List Home]


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


Michael,

I understand what you're saying but I am talking about the hierarchy of the docBook. There could be just one element that would have a default attribute unless it is provided with an override. The complexity would be shifted from the elements to the attributes. This may not be an answer for every element but at the moment there is such a reduction. For example <itemizedlist> is provided rather than <smalldotitemizedlist> and <opencircleitemizedlist> and <largedotitemizedlist>. The presentation details are handled by the attribute as could a caution versus a warning, where an attribute could be used to display one differently than another for each <admonition> or <attention> element.

In most circumstances the complexity will always be there. It is more a question of where the complexity can be more easily maintained.

Jeff

Michael Smith wrote:
20030602063328.GA1552@donnybrookfair">
Jeff Biss <jeff@marco-inc.com> 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 only sense in which that kind of approach would decrease the
complexity of DocBook or any other markup vocabulary is that it would
hinder implementors and authors from doing further open-ended or
unconstrained sub-typing of any unique logical unit (e.g., a tip) that's
modeled as an attribute value instead of as a element.

That is, they could no longer use their own custom attribute values to
specify different types of tips to distinguish them from one another --
e.g., <tip role='hint'> and <tip role='suggestion'> (or whatever).

Otherwise, reducing the total number of existing elements by
substituting them with attribute values does nothing to reduce the
complexity of the vocabulary or make it any easier to learn. The number
of unique logical units that users need to deal with remains the same.



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