--- Karl Eichwalder <[EMAIL PROTECTED]> wrote: > Shaun McCance <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED]@! come-ons? Let our SpamGuard protect you. http://uk.docs.yahoo.com/nowyoucan.html _______________________________________________ gnome-doc-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/gnome-doc-list
