[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Re: DOCBOOK: Re: RFE 472229: Allow HTML Tables in DocBook
Eduardo Gutentag <eduardo.gutentag@sun.com> writes: > Norman Walsh wrote: > > > > / Eduardo Gutentag <eduardo.gutentag@sun.com> was heard to say: > > | Option 2 [Instead of using namespaces, limit users to having > > *either* HTML tables *or* CALS tables in a doc instance, but not both] > > makes much more sense to me. > > > > Why? > > Aw shoot, I had to speak up, didn't I? > > Off the top of my head: > a) because historically Docbook never attempted to get ahead of future > tools or sooner-or-later use cases > > [...] > > e) because tools vendors (i.e. editor vendors) would probably have a much > harder time implementing option 1 than option 2. It seems like a big benefit we'd get from allowing HTML tables in DocBook is that we could then use existing WYSIWYG HTML editors to graphically create and edit tables, instead of marking them up completely by hand (e.g., not using one of the commercial XML editors that support WYSIWYG editing of CALS tables.) I don't know much about WYSWIG table-editing support in commercial HTML editing apps, but I do know that Amaya, the W3C's open-source HTML browser/editor, lets you create and edit valid XHTML tables graphically. (And do WYSWIG editing of SVG graphics and MathML too.) I think a lot of DocBook users would find it very useful to be able to do WYSWIG table editing in Amaya or some other application, and then just cut-and-paste the table markup into Emacs/PSGML or whatever XML editing app they use. And maybe it'll be easier for some of the nascent open-source WYSIWYG XML editing apps (like Yann Dirson and Benjamin Drieu's ThotBook[1], Daniel Naber's XML plugin[2] for KDE's Kate, and Richard Moore's KDE-associate XMLElegance[3]) to get off the ground if they only need to deal with HTML tables (initially at least) and not with CALS. I think the namespace option will be the way to go when the common tools can handle it. But it seems like it wouldn't gain us much until it's supported by more applications. For the short term at least, the either-HTML-or-CALS option seems more practical and useful to me. [1] http://www.freesoftware.fsf.org/thotbook/ http://savannah.gnu.org/projects/thotbook/ http://lists.oasis-open.org/archives/docbook-apps/200109/msg00109.html [2] http://www.danielnaber.de/tmp/ [3] http://www.ipso-facto.demon.co.uk/development/xmelegance/xmelegance.html
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC