OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

docbook message

[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/

[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