This is the mail archive of the
docbook@lists.oasis-open.org
mailing list for the DocBook project.
Re: [docbook] Ruminations on the future of DocBook
- From: Dave Pawson <dpawson at nildram dot co dot uk>
- To: Norman Walsh <ndw at nwalsh dot com>, docbook at lists dot oasis-open dot org
- Date: Fri, 30 May 2003 18:15:08 +0100
- Subject: Re: [docbook] Ruminations on the future of DocBook
At 14:57 29/05/2003 -0400, Norman Walsh wrote:
For DocBook, I think that time has come.
More thinking is definitely in order. By more minds than mine, which
is why I'm publishing these essays now.
From which.
We'd use XML.
+1
We'd use RELAX-NG.
+0, but either DTD's or relax-ng, not xsd.
We'd design for the web.
+1, if pdf from xsl-fo was included.
We'd design for regularity and consistency at the current scale.
Or have a two stage design?
A docbook simple + a stricter scaled up version?
Is it the variability that causes the processing problems, and user
confusion?
We'd almost certinaly put it in a namespace.
+0
(AF via XML tools is dead then?)
Perhaps controversially, we might allow foreign namespace elements to creep in.
+1 to dc for 'some' form of metadata
I'd request that each additional foreign ns be put to the vote?
Whatever we do, it should still look and feel like DocBook.
I'd even query that Norm.
Docbook for technical markup is a strong user of the schema...
what are the other users?
what are the percentages?
I guess I'm saying that the tech doc usage possibly isn't the 80-20
anymore?
http://www.dpawson.co.uk/docbook/reference.html#d12e91
I think one of the goals should be that most valid DocBook documents can
be transformed into new valid V.next documents with XSLT.
+1 on that, perhaps even if some manual work is needed?
You ask:
Is the distinction between formal/informal useful anymore?
I think so, just that it's relatively unknown except by the few?
I found it enlightening.
Re linking.
Suggest three simple forms.
1. Internal to this file
2. External, as per html a href
3. External, to another file in this 'document' (olink class)
Nothing more.
4. Inlines.
I'd focus on the end user? *which* one should I use? Even to the extent of
less is better.
...publish some normative entity sets ...
I'd go even further. If we can assume that memory is becoming less of a
problem,
include a reasonably complete set by default.
Maybe it would it be better to just declare DocBook finished and move on?
Speaking from the non legacy viewpoint, yes,
which presumes that the present stylesheets would remain available for
legacy use, possibly even separate development by an interested user group?
From
http://norman.walsh.name/2003/05/29/moredocbook
Re
Rationalizing Inlines
I'd suggest an approach of being really hard, only then coming back under
pressure
to add elements back in. (Your comment about legacy didn't ring true with
the general
approach of this being a fresh start?)
Re cruft.
* caption. Maybe we should allow captions on figures, but allowing them
on mediaobject is clunky.
Question the ability to produce a M$ pop-up (tool tip), as well as
providing the longdesc;
more specifically in light of xhtml 2 moving totally away from img to
object. How might
the two align?
Re the prototype;
I'm annoyed since emacs has given me docbook support for 4 years.
I'm still looking for a syntax directed editor that will pick up a relax-ng
schema.
regards DaveP
---------------------------------------------------------------------
To unsubscribe, e-mail: docbook-unsubscribe@lists.oasis-open.org
For additional commands, e-mail: docbook-help@lists.oasis-open.org