This is the mail archive of the 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]

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.
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.
(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?
I think one of the goals should be that most valid DocBook documents can be transformed into new valid 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?



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:
For additional commands, e-mail:

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