Re: [docbook] Ruminations on the future of DocBook

[Dave Pawson <dpawson@nildram.co.uk>]

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