Re: Successor to DocBook

[Joachim Noreiko <jnoreiko yahoo com>]

--- Karl Eichwalder <ke suse de> wrote:

> Shaun McCance <shaunm gnome org> writes:
> 
> > Why not just give all the elements simple and
> consistent names
> > to begin with?  Nobody can even remember the
> DocBook elements,
> > so what's the point of catering to that
> experience?
> 
> The good thing about DocBook is, that it is by now
> an accepted standard
> in the free software and open source community. 
> Many developers and
> writers are sufficiently enough familiar with the
> DocBook markup.  Even
> if some element names are weird, it might make sense
> to keep them
> because we have learnt them (and beginners can learn
> them as well
> without too much trouble).
> 
> Yes, I'm quite conservative.  I'd say we should wait
> another 10 years
> before start to push the next DTD/Schema onto the
> community.  ATM, the
> problem is not the markup per se, but the lack of a
> free XML editor.  We
> need a combination of oxygen and emacs
> (psgml/nxml/xml).

A combination of what...?

I haven't heard of Oxygen, but I found this: 
http://www.oxygenxml.com/xml_editor_mac_os_x.html

That looks way too complex for what a docs writer like
myself might need.
I looked into xml editors when I started working on
documentation. They mostly crashed. 
The only time I found a real need for them is when I
wanted to rearrange large chunks of the user guide: I
wanted to collapse sections and then drag-and-drop
them. Trying to do this usually moved only the title
of the collapsed section... or crashed.

And as for emacs... The 1980s called. They want their
software back.

I use gedit. For large files it can be cumbersome to
keep track, but topic-based Mallard would solve that
:)
Sometimes I use bluefish, because I like its tag
completion. But I don't like its poor integration with
Nautilus and it's slow with large files, so I go back
to gedit for a while :)

That pretty much works for me. 
I know <section>, <para>, <application>. Anything else
I have to look up the DocBook reference, so even if I
had a fancy editor that inserted them for me, I
wouldn't know which to use.
In particular:

Why is linking to other documents so awkward? In
topic-based Mallard, nearly every link will be to
another file. I want <xref> to a) be a nicer name and
b) work with any sort of link to gnome docs, so I
don't have to add the title manually.
Why do screenshots have to be wrapped in so much guff?
How do I mark up commands the user should type into
the terminal?
What's the point of having so many different tags for
menu items -- guimenu, submenu, menuchoice and so on?
What information can feasibly be optained from this
distinction?
On the flip side, why only guilabel? I have to use
this for window titles, for dialog labels, for things
that aren't even labelled in the GUI (eg a folder's
parent selector in Nautilus).

> ;)  I still believe that DooBook is good enough.  If
> you want "topics"
> use unnumbered section elements; if special link
> tags are actually
> missing, import them using namespaces.

I wonder what Shaun has in mind for creating the
contents pages -- I expect these would be in the same
markup as the topics, since we currently often have
intro text on our chapter contents pages. A list of
topic nodes is itself a topic node.
Can DocBook handle that?


		
___________________________________________________________ 
All New Yahoo! Mail ? Tired of Vi gr@! come-ons? Let our SpamGuard protect you. http://uk.docs.yahoo.com/nowyoucan.html