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

Hash: SHA1

/ Morus Walter <morus.walter@tanto-xipolis.de> was heard to say:
| Norman Walsh writes:
|> 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.

Point taken. But even in the middle ground, you have still have "n" choices
whether you have n elements or (n-m) elements and m attributes.

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

Well, do you really? Suppose we had admonition with a role attribute.
If you want to insert a warning, you have to know to insert an
admonition and then set the class attribute value.

For schemas that offer a large number of choices, some grouping
mechanism is definitely useful, but this is at least in part a UI

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

I agree. The element/attribute distinction is partly subjective.

                                        Be seeing you,

- -- 
Norman Walsh <ndw@nwalsh.com>      | Before doing someone a favour,
http://www.oasis-open.org/docbook/ | make sure that he isn't a
Chair, DocBook Technical Committee | madman.--Eugéne Labiche
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: Processed by Mailcrypt 3.5.7 <http://mailcrypt.sourceforge.net/>


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