This is the mail archive of the docbook@lists.oasis-open.org mailing list for the DocBook project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[docbook] Re: Ruminations on the future of DocBook


-----BEGIN PGP SIGNED MESSAGE-----
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
issue.

|> 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,
                                          norm

- -- 
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
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: Processed by Mailcrypt 3.5.7 <http://mailcrypt.sourceforge.net/>

iD8DBQE/FuVcOyltUcwYWjsRArCAAJwNG5FcLUHAcSJn2T4b+HXHWOhcdgCggRsy
dfpQyZWQFJcOzpvzvXyBzr0=
=tHWj
-----END PGP SIGNATURE-----

---------------------------------------------------------------------
To unsubscribe, e-mail: docbook-unsubscribe@lists.oasis-open.org
For additional commands, e-mail: docbook-help@lists.oasis-open.org


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]