WYSIWYG Editor for DocBook DTD Content?

Saqib Ali asks: "This week I saw a demo of the Tagless Editor by i4i. The editor is a plugin to Microsoft Word, which can be used to create XML based content. The plugin can handle various custom DTDs. However it can not properly handle the DocBook DTD. I was wondering if there is any WYSIWYG XML editor that can be used to edit DocBook DTD based content? Any ideas?"

Comments

Re:not necessary

[DeadMoose]

One of the great things about XML is that it's human-readable and -writeable. You don't need a WYSYWIG editor, because you can just edit it directly. Once again, we find that open standards are superior to the proprietary alternatives pushed by the likes of Microsoft and Sun.

Except for the fact that it's really convenient to not have to edit the raw XML. Yes I can, but I really don't want to; I'd much rather save myself that agrivation and just write what I'm trying to write.

It's just like a lot of other things that people go "well, you can do it manually, so why do you need a fancy tool?" about. Yes, I can manually patch/build/blahblah my own kernel. Do I want to? No, I want to just have things work. Same story here: do I want to sit here remembering what all the docbook tags are? No. Did I want to learn them in the first place? No. There's a time and a place for good tools to make tedious tasks easier.

Just because I could edit a file and manually set all the colors for all the pixels, doesn't mean there's no need for Photoshop/The Gimp.

Docbook and WYSIWYG...

[Papineau]

The only problem I see is that Docbook doesn't have a visual representation, it has many, depending on the backend you want (HTML, PDF, PS, TXT, etc.). So a WYSIWYG editor would only show one type of representation.

Besides, Docbook (as many other document formats) is meant to separate the visual from the info. Linking the visual to the edition would only make people try to make it present the info in (what they beleive to be) pretty layout, when Docbook's goal is to concentrate on the structure of the document, which the backend then translates to HTML tags, or PDF fonts and layout, etc.

Structured Editor

[Crutcher]

I agree, you don't really want a WYSIWYG editor for docbook, as that violates the Information/Representation sepperation.

But what would be _really_ useful would be a structured editor, which provided a good mapping at several levels (ala Mozilla's composer, where I can turn on and off tabs). The point of such an editor's representation would not be for final production, but to unambigously display the information's _structure_ to the user, and to facilitate manipulating that structure.

It would be like a very ugly word processor, where the tables would always have borders, etc.

If that editor was then linked with a set of generation tools, to make it EASY to genearte and view PostScript, HTML, XHTML, etc. productions, then you'd really have something. I'd use it, for sure, and I don't mind using docbook tags now.

In fact, would mozilla's composer be a good place to start with a docbook editor? Mozilla has good DOM tools, like the inspector, which loads XML DocBook files just fine.

Re:not necessary

[GigsVT]

You are missing the point, the whole point is to seperate the content from presentation. WYSIWYG is totally contrary to that. I'd go as far as to say that it's entirely impossible to have such a Docbook editor, since you have pretty much no say in the presentation when you write it. It's the same with any good implementation of XML.

Re:not necessary

[Twirlip of the Mists]

You are missing the point, the whole point is to seperate the content from presentation.

No offense intended, but I think it is you who is missing the point. The average person doesn't think in XML. The average person thinks in formatted text. When I'm writing, I don't think "<ital>foo</ital>," I think "foo." Being able to see foo on the screen, but get "<ital>foo</ital>" in the output is a big win.

I'd go as far as to say that it's entirely impossible to have such a Docbook editor, since you have pretty much no say in the presentation when you write it.

Oh, sure you can. The editor doesn't need to display it the exact same way the end-user will display it; it just needs to display it in a way that makes the user feel comfortable. On your machine, chapter titles are 24 point serif type; on mine, they're 18 point italic sans-serif type. I don't care that yours are different from mine; I only care that mine look the way I expect them to.

Re:not necessary

[sporktoast]

When I'm writing, I don't think "<ital>foo</ital>," I think " foo."

Ok then. Why should foo be italicized? Is it important? Is it an example some something? A variable? A citation? A proper name? A bit of sarcasm? Maybe you just *like* the way italics look and don't really mean anything more by it. Then, perhaps "<ital>foo</ital>," is something of a win. But if "foo" means more than that, then "<ital>foo</ital>," actually loses that meaning.

Oh, sure you can. The editor doesn't need to display it the exact same way the end-user will display it; it just needs to display it in a way that makes the user feel comfortable. On your machine, chapter titles are 24 point serif type; on mine, they're 18 point italic sans-serif type. I don't care that yours are different from mine; I only care that mine look the way I expect them to.

But that's not really WYSIWYG then, is it? (Unless you want to get all semantic about the Ys in the acronym.) The thing is, if you lobotomize the meta-data so that what you create as a <chapter title> is encoded as <ital>, then you are pretty much forcing the hand of my machine. Your "big win" becomes my loss. Sure, I can remap <ital> so that it renders as 24 point serif, but then everything else that you've flattened down to <ital> for the sake of how it looks (footnotes, dates, marginal commentary, etc.) gets the 24 point serif treatment, too.

WYSIWYG for DocBook? You're gonna need a bigger wrench if you want to pound in that screw.