--gvF4niNJ+uBMJnEh
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
Catching up on my e-mail.
On Tue, Oct 16, 2001 at 01:56:25PM -0400, Norman Walsh wrote:
There's been a fair amount of discussion about how to make DocBook
Nik Clayton [EMAIL PROTECTED] writes:
[...]
Didn't Mike Smith come up with a nifty way of remapping DocBook elements
to other element names?
I wrote a simple XSLT stylesheet that 1)looks through a document for
any elements having an attribute with a certain name (which you
specify with an
:
Subject:Re: DOCBOOK: A straw proposal for help topics in DocBook
I wrote:
|So it looks like if we use a Section-like (instead of
Chapter-like)
|content model for Topic, it'll mean that Topics can contain only
|recursive Sections, not numbered ones (Sect1-Sect5
Norman Walsh [EMAIL PROTECTED] writes:
/ Michael Smith [EMAIL PROTECTED] was heard to say:
|So it looks like if we use a Section-like (instead of Chapter-like)
|content model for Topic, it'll mean that Topics can contain only
|recursive Sections, not numbered ones
On Thu, 18 Oct 2001, Michael Smith wrote:
But the content model Norm proposed for Topic is recursive, just like
the one for Section is -- that is, a Topic can contain other Topics,
nested indefinitely. So you could do:
chapter
titleHow to Drive/title
topic id=1000 role=topic
On Thu, 18 Oct 2001, Michael Smith wrote:
However we decide to model it, it seems like Refentry needs to be
allowed in there somewhere.
Agreed.
And if we do add a recursive topic element to divcomponent.mix, I too
would be strongly opposed to allowing it to contain other sectioning
Gershon L Joseph [EMAIL PROTECTED] writes:
On Thu, 18 Oct 2001, Michael Smith wrote:
[...]
Also, does it make sense to model a help topic as a recursive element?
What I mean is, in most (or maybe all) current online help systems,
each help topic is actually a single HTML page/webpage
I wrote:
|So it looks like if we use a Section-like (instead of Chapter-like)
|content model for Topic, it'll mean that Topics can contain only
|recursive Sections, not numbered ones (Sect1-Sect5), and that
|Topics can't contain Refentrys at all (or Simplesect).
Norm wrote:
1. Online-help peer to Set. Do we actually need one?
It would be useful for us. We currently package our book set containing
documentation on all of our products, with one version installable into an
online helpviewer in the QNX operating system. Most of our products can work
together,
/ Michael Smith [EMAIL PROTECTED] was heard to say:
| 1. Online-help peer to Set. Do we actually need one? What will the
|processing expectations be for it? Do any of the existing help
|systems -- HTML Help, Javahelp, or whatever -- provide any way for
|packaging up sets of HTML Help
At 13:56 16/10/2001 -0400, Norman Walsh wrote:
What's the plan:
The overall plan is to allow people to author Help Sets using all of
the rich technical structure of DocBook without shoe-horning it into
the classical print book model.
Guessing that 'topics' could be viewed in a similar way to
| 3. Content model for the set-of-topics element (Helpproject). Does
it
| need to include the navigational components (ToC,
LoT, Index)?
| These seem useful only if authors want to
manually author ToCs,
| LoTs, and Indexes, instead of leaving it up to
the
| stylesheets/helpcompiler to generate
/ Nancy (Paisner) Harrison [EMAIL PROTECTED] was heard to say:
| I, on the other hand, am concerned with not allowing sections in the
| mix, since that removes a transparent way to reuse data between
| print and online delivery.
If you need sections in a topic, use nested topics. Allowing
|So it looks like if we use a Section-like (instead of Chapter-like)
|content model for Topic, it'll mean that Topics can contain only
|recursive Sections, not numbered ones (Sect1-Sect5), and that
|Topics can't contain Refentrys at all (or Simplesect).
I am strongly opposed to
14 matches
Mail list logo
