From: Doug du Boulay [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Subject: Re: DOCBOOK: Re: On the size of DocBook...
Date: Mon, 09 Sep 2002 11:28:35 +0900
If you make it modular, so that someone can create and install ChemBook
or
MusicBook, then it satisfies 2 and 3. Since users are likely
On Sun, Sep 08, 2002 at 05:20:38AM +, Matt G. wrote:
This may not please application developers, but I think that users who
don't care enough about semantics that they would use a wysiwyg-style
editor don't typically need domain-specific semantics. Just create a
core DocBook that has
. september 2002 01:04
To: Adam Turoff
Cc: [EMAIL PROTECTED]
Subject: DOCBOOK: Re: On the size of DocBook...
/ Adam Turoff [EMAIL PROTECTED] was heard to say:
|On Fri, Sep 06, 2002 at 05:14:18PM -0400, Norman Walsh wrote:
| Quite. Hard that is. And it would introduce N! different DocBooks.
| How
A few things occur to me.
1. The difference between 400 elements and 800 elements isn't
significant, just add 'em all.
Doesn't scale. Adding them is work. Maintaining them is more work. Why
would the TC want to undertake all of this?
2. 400 is just too many, we need to make DocBook
On Sunday 08 September 2002 14:20, Matt G. wrote:
At 09:39 2002 09 05 -0400, Norman Walsh wrote:
A few things occur to me.
1. The difference between 400 elements and 800 elements isn't
significant, just add 'em all.
Doesn't scale. Adding them is work. Maintaining them is more work. Why
/ Dave Pawson [EMAIL PROTECTED] was heard to say:
| What impact might that have on the stylesheets Norm?
| Divergent sets of stylesheets for pizza slices?
No, no, no. You slice up the pie, you get a strict subset of the whole
pie. The stylesheet for the whole pie can always be applied to the
On Fri, Sep 06, 2002 at 03:24:09PM -0400, Norman Walsh wrote:
Why is Simplified DocBook easier to use than full DocBook?
1. Because when you open the DTD in emacs and read the content models,
it's smaller.
2. Because the user documentation for Simplified lists fewer elements.
3.
Adam Turoff wrote:
On Fri, Sep 06, 2002 at 03:24:09PM -0400, Norman Walsh wrote:
Compelling anecdotal stuff about trying to introduce DocBook to new
users snipped out./
Just for kicks, how difficult would it be to refactor DocBook into
a simple core (based on Simplified DocBook, or the
/ Adam Turoff [EMAIL PROTECTED] was heard to say:
[...]
Taking things slightly out of order...
| Just for kicks, how difficult would it be to refactor DocBook into
| a simple core (based on Simplified DocBook, or the moral equivalent),
| and implement the full DTD as multiple layers of
On Fri, Sep 06, 2002 at 05:14:18PM -0400, Norman Walsh wrote:
/ Adam Turoff [EMAIL PROTECTED] was heard to say:
| Just for kicks, how difficult would it be to refactor DocBook into
| a simple core (based on Simplified DocBook, or the moral equivalent),
| and implement the full DTD as multiple
/ Adam Turoff [EMAIL PROTECTED] was heard to say:
|On Fri, Sep 06, 2002 at 05:14:18PM -0400, Norman Walsh wrote:
| Quite. Hard that is. And it would introduce N! different DocBooks.
| How easy would that be to explain?
|
|I thought it would be difficult. How would I explain N! DocBook DTDs?
At 22:14 06/09/2002, Norman Walsh wrote:
/ Adam Turoff [EMAIL PROTECTED] was heard to say:
[...]
Taking things slightly out of order...
| Just for kicks, how difficult would it be to refactor DocBook into
| a simple core (based on Simplified DocBook, or the moral equivalent),
| and implement
At 00:03 07/09/2002, Norman Walsh wrote:
| I suspect it wouldn't be difficult at all. Most of that work is
| already done in TDG. Identifying the most important core 25-50
| elements might be a little tricky,
I tried to identify the core 25-50 elements, I wound up with more than 100.
Start
13 matches
Mail list logo
