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] Re: Ruminations on the future of DocBook

Morus Walter <morus.walter@tanto-xipolis.de> writes:

> 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.

If that's the case, maybe it's because the point wasn't stated clearly. :)

What is the point of "reducing the number of tags" in an schema by
substituting them with attribute values? It certainly does not simplify
the structure. The resulting attributes-everywhere schema will be
equally as complex as the original discrete-elements schema -- though
it'll become much less open-ended/versatile/extensible.

> 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.

I agree that markup selection should be much easier than it is in
current editing apps. But I think it's a bad idea to make schema changes
in order to work around deficiencies in current editing apps.

A better solution would be to make the editing apps smarter. For
example, xemacs/psgml could provide a option to display its insert tag
list with elements in logical groupings.

The logical groupings could be specified in a some kind of simple format
in text file the editing app would read along with the schema. And
different authors/authoring groups could create or customize the file to
specify logical groupings that best fit their needs (because for a big
schema like DocBook, it's not likely that everybody's going to agree
about what the logical groupings should be, and which groupings certain
elements should go into).

> > 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.

But you might think differently if you were writing a book about SGML or
XML and wanted to distinguish, say, different types of Attributes from
one another. If you had an Attribute element, you could do:

   <attribute class="cdata">role</attribute>
   <attribute class="enumerated">class</attribute>
   <attribute class="idref">endterm</attribute>

I think that some ease-of-use and ease-of-learning is also sacrificed
when we decide to go with attribute values instead of discrete elements.
For example, in DocBook 4.2, the class attribute on Systemitem element
now has 16 possible enumerated values, "newsgroup" among them. Marking
up a newsgroup name with <systemitem class="newsgroup"> doesn't seem
particularly intuitive to me.


PGP signature

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