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

 


Help: OASIS Mailing Lists Help | MarkMail Help

Mail Index message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: docbook-digest Digest #191

DOCBOOK: DocBook and Zope
Re: DOCBOOK: Re: syntax=""
RE: DOCBOOK: Altova AUTHENTIC - is now Free
RE: DOCBOOK: Altova AUTHENTIC - is now Free
Re: DOCBOOK: Altova AUTHENTIC - is now Free
RE: DOCBOOK: Altova AUTHENTIC - is now Free
DOCBOOK:
DOCBOOK: DocBook vs OpenOffice.org
Re: DOCBOOK: DocBook vs OpenOffice.org
DOCBOOK: The right tool for my task
Re: DOCBOOK: DocBook vs OpenOffice.org
Re: DOCBOOK: The right tool for my task
DOCBOOK: marking up keycaps according to their semantics
Re: DOCBOOK: DocBook vs OpenOffice.org
RE: DOCBOOK: DocBook vs OpenOffice.org
Re: DOCBOOK: Altova AUTHENTIC - is now Free
DOCBOOK: XHTML tables
DOCBOOK: subsetting: excluding CALS table
Re: DOCBOOK: XHTML tables
Re: DOCBOOK: subsetting: excluding CALS table
Re: DOCBOOK: subsetting: excluding CALS table
Re: DOCBOOK: subsetting: excluding CALS table
Re: DOCBOOK: subsetting: excluding CALS table
Re: DOCBOOK: subsetting: excluding CALS table

----------------------------------------------------------------
To subscribe or unsubscribe from this elist use the subscription
manager: <http://lists.oasis-open.org/ob/adm.pl>


Hi all,

Ron Bickers has created a DocbookDocument product for Zope. Has anyone 
heard about that and knows how it works or has good links to example files?

It is in the development now, is it usable or is it full of bugs?

any comments, please!

Thanks in advance

Sorin Marti




Norman Walsh wrote:


> | Should I file an RFE?
> 
> Sure.


Done:
http://snurl.com/v2i
(RFE 692319)
(second try; first one disappeared)


Tobi

-- 
http://www.pinkjuice.com/





> De : Alexander Voropay [mailto:a.voropay@vmb-service.ru]
> Altova AUTHENTIC - Free License XML editor with DocBook support
> http://www.altova.com/products_doc.html

Are you sure it's free ? What I could download on their site is not free at
all, it's just a 30-day free evaluation, that I can't even launch because I
already tried it a few months ago.

Cheers,
Rodrigo



When the license manager app starts, click the "Purchase" button. It
will take you to a page where you can "Purchase" Authentic for free (you
have to enter an email address). They'll email you a key.

I'm poking around in it now with a small doc. From what I can tell the
".sps" file for docbook (a set of instructions that tells Authentic how
to present an instance of docbook) isn't written all that well, but
you'll get the idea--it's a way to create forms/templates for
non-xml-aware content providers. Does anybody have/know of a better
DocBook.sps than the one provided? I can imagine each user would need to
customize it to some degree, but I think there could be a better
starting point (for example, insert an <important> and you're invited to
add a <title>, but I can't seem to get it to let me insert a <para>?!?).


The real test will be when I try opening one of our big docs in it... 

David

-----Original Message-----
From: rodrigo reyes [mailto:rodrigor@in-fusio.com] 
Sent: Friday, February 28, 2003 10:40 AM
To: Docbook@Lists. Oasis-Open. Org
Subject: RE: DOCBOOK: Altova AUTHENTIC - is now Free


> De : Alexander Voropay [mailto:a.voropay@vmb-service.ru]
> Altova AUTHENTIC - Free License XML editor with DocBook support
> http://www.altova.com/products_doc.html

Are you sure it's free ? What I could download on their site is not free
at
all, it's just a 30-day free evaluation, that I can't even launch
because I
already tried it a few months ago.

Cheers,
Rodrigo



David Cramer wrote:
> When the license manager app starts, click the "Purchase" button. It
> will take you to a page where you can "Purchase" Authentic for free (you
> have to enter an email address). They'll email you a key.
> 
> I'm poking around in it now with a small doc. From what I can tell the
> ".sps" file for docbook (a set of instructions that tells Authentic how
> to present an instance of docbook) isn't written all that well, but
> you'll get the idea--it's a way to create forms/templates for
> non-xml-aware content providers. Does anybody have/know of a better
> DocBook.sps than the one provided? 

I've customized my sdocbook DTD, therefore I can't open any of my files 
in this product. A message window comes up stating that there is no .sps 
file for my document, that the license does not allow source view of 
instances and that I should go to the "stylesheet" application and 
create a new .sps file for my file. I have been unable to find the 
stylesheet application, either on disk in the installation or as a menu 
option in Authentic itself. If I am right, there is certainly something 
authentic about the free-ness of this product but it's not in the name 
or the functionality.

             ...edN






David Cramer [mailto:dcramer@motive.com] wrote:

> I'm poking around in it now with a small doc. From what I can tell the
> ".sps" file for docbook (a set of instructions that tells Authentic how
> to present an instance of docbook) isn't written all that well

 You could try this DocBook.sps . I extracted it from XMLSpy 4.0
(trial) with tiny correction (to DocBook 4.2). Is seems, this file isn't
copyrigted, so you could use it as you want.
Unfortunately, it looks slightly ugly... but it works. I think we
should cutomize it, starting from this point.

Editor template:
http://monitor.vmb-service.ru/~alec/DocBook.sps
Example file:
http://monitor.vmb-service.ru/~alec/DocBook.xml


--
-=AV=-





-- 
+++ GMX - Mail, Messaging & more  http://www.gmx.net +++
Bitte lächeln! Fotogalerie online mit GMX ohne eigene Homepage!




Hi,

I'm new to DocBook. As far as I know there is a DocBook version based on
XML. I know OpenOffice.org a little bit which is based on XML, too, and thus can
be transformed to many other formats. Can you tell me what would be the
advantages of using DocBook instead of OpenOffice.org? What the disadvantages?
For what task would you suggest the one and for what the other?
And is there a WYSIWYG-editor that uses DocBook as its file format?

Thanks for your answers.

Greez
Florian

-- 
+++ GMX - Mail, Messaging & more  http://www.gmx.net +++
Bitte lächeln! Fotogalerie online mit GMX ohne eigene Homepage!




Florian Brunner (fbrunnerlist@gmx.ch) wrote:

> I'm new to DocBook. As far as I know there is a DocBook version based on
> XML. I know OpenOffice.org a little bit which is based on XML, too, and thus can
> be transformed to many other formats. Can you tell me what would be the
> advantages of using DocBook instead of OpenOffice.org? What the disadvantages?
> For what task would you suggest the one and for what the other?
> And is there a WYSIWYG-editor that uses DocBook as its file format?

I like & use epcEdit (www.epcedit.com).

Sincerely,
Gour

-- 
Gour
gour@mail.inet.hr
Registered Linux User #278493




Hi,

I have another question. I have a particular task and would like to know if
you think DokBook is the right tool for this task:
I have a Java library and would like to make a tutorial structured similar
to http://java.sun.com/docs/books/tutorial/
The tutorial consists of different trails each consisting of different pages
and a TOC linked together. The layout of the header and footer of these
pages should be the same for all of them, just the links do change. So I would
like to specify the header and footer at a single place with parameters to
configure them. And I would like that the TOC is generated automatically. Of
course I could do that with a CGI-program but I would like to have a bunch of
static HTML-files in the end, so one could view the tutorial offline without
needing a CGI-capable webserver at hand.
Is it possible to do this in DocBook and then generate these HTML-pages? Or
is there a better tool for this task? Note that images, links and links
behind images should be supported. (Is it possible to generate a HTML-file that
embeds an applet?)

Thanks for your help.

Greez
Florian

-- 
+++ GMX - Mail, Messaging & more  http://www.gmx.net +++
Bitte lächeln! Fotogalerie online mit GMX ohne eigene Homepage!




On Saturday, March 1, Florian Brunner wrote:
> Hi,
> 
> I'm new to DocBook. As far as I know there is a DocBook version
> based on XML. I know OpenOffice.org a little bit which is based on
> XML, too, and thus can be transformed to many other formats. 

> Can you tell me what would be the advantages of using DocBook
> instead of OpenOffice.org?

Hi Florian,

There's an OpenOffice sub-project to provide DocBook Filters so that
you can save your files as DocBook XML, thereby using OpenOffice as a DocBook
editor. Presumably, you then get the benefits of both.

I'm not sure how far the project has progressed, but you can get & test the
latest version of the filter available at

  http://xml.openoffice.org/xmerge/docbook/

> For what task would you suggest the one and for what the other?

OpenOffice is an MSOffice-like integrated desktop application
suite. It has a word processor, spreadsheet, drawing, & presentation
tools.

A DocBook file, OTOH, has no preferred presentation, it's simply a
bunch of text surrounded by XML tags. It's used mainly to write
computer-related documentation and is processed into some output format in a
separate procedure.

> And is there a WYSIWYG-editor that uses DocBook as its file format?

See the OpenOffice filter I mentioned above, plus there are a number of both
free and commercial editors that'd work for DocBook. I only use GNU Emacs,
so my knowledge of other tools is quite limited.

You might want to checkout the 'DocBook Tools' section of the DocBook wiki:

 http://www.docbook.org/wiki/moin.cgi/DocBookTools

Good luck!

Cheers,
Mark
-- 
_____________________________________
Mark Johnson        <mark@dulug.duke.edu>
Debian XML/SGML     <mrj@debian.org>
Home Page:          <http://dulug.duke.edu/~mark/>
GPG fp: 50DF A22D 5119 3485 E9E4  89B2 BCBC B2C8 2BE2 FE81



Florian Brunner <fbrunnerlist@gmx.ch> writes:

> The tutorial consists of different trails each consisting of different pages
> and a TOC linked together. The layout of the header and footer of these
> pages should be the same for all of them, just the links do change. So I would
> like to specify the header and footer at a single place with parameters to
> configure them. And I would like that the TOC is generated automatically. Of
> course I could do that with a CGI-program but I would like to have a bunch of
> static HTML-files in the end, so one could view the tutorial offline without
> needing a CGI-capable webserver at hand.
> Is it possible to do this in DocBook and then generate these HTML-pages? Or
> is there a better tool for this task? Note that images, links and links
> behind images should be supported. (Is it possible to generate a HTML-file that
> embeds an applet?)

This is definitly possible. There are XSL stylesheets to generate a
bunch of HTML files from Docbook, including a ToC, an index etc., and
they are faily customizable.

Of course, it would help if you know XSLT well if you want to
implement significant customizations. :-)

Regards
Henrik




Hi

"Pragmatic Programmer" [1] Dave Thomas writes on his blog [2]:

"[...]
Here's how the FAQ recommends you mark up the Emacs key sequence C-h C-f 
(control H, followed by control F, which normally displays help on a 
function).

<keycombo action="seq">
   <keycombo action="simul">
     <keycap>C</keycap>
     <keycap>h</keycap>
   </keycombo>
   <keycombo action="simul">
     <keycap>C</keycap>
     <keycap>f</keycap>
   </keycombo>
</keycombo>

Whoa! Some markup! And at first sight, pretty logical: a keyboard 
combination consisting of a sequence of two simultaneous key presses, 
the first a 'C' and an 'h', the second a 'C' and an 'f'.

Except, this isn't logical markup at all. It is some remarkably verbose 
hybrid. It totally fails to convey the most important fact about the 
keys you press, namely that you are pressing control and h, followed by 
control and f. Instead, it simply encapsulates the Emacs convention of 
showing an uppercase 'C' to mean control.

And why is this bad? Because I want true logical markup. In LaTeX, I'd 
define some macros to let me write

\KeySeq{\Control{h} \Control{f}}

This (to my mind) a lot easier to read and type. But more importantly, 
it gives me the flexibility I need. Perhaps in online documentation I 
want to use the 'C-h' convention. No problem, I just write the macro 
appropriately and every control sequence is documented accordingly. If a 
publication says that their standard for control keys is "^h ^f", then a 
single change to the macro updates the whole document. And if I want to 
use fancy pictures of keys, my macros can do that too.
[...]"

I agree that there should be a way to markup the control key as control key.
If we choose what's printed on the key, then that would be Strg for 
German keyboeards, Ctrl for english ones, etc.
role="control-ley" doesn't cut it either; it would work with one set of 
transformation tools, but not with a different set.

Tobi

[1] http://www.pragmaticprogrammer.com/
[2] http://pragprog.com/pragdave/
[3] http://pragprog.com/pragdave/Bitches/LogicalMarkup.rdoc,v

-- 
http://www.pinkjuice.com/




On Sat, 2003-03-01 at 13:30, Mark Johnson wrote:
> On Saturday, March 1, Florian Brunner wrote:
> > Hi,
> > 
> > I'm new to DocBook. As far as I know there is a DocBook version
> > based on XML. I know OpenOffice.org a little bit which is based on
> > XML, too, and thus can be transformed to many other formats. 
> 
> > Can you tell me what would be the advantages of using DocBook
> > instead of OpenOffice.org?
> 
> Hi Florian,
> 
> There's an OpenOffice sub-project to provide DocBook Filters so that
> you can save your files as DocBook XML, thereby using OpenOffice as a DocBook
> editor. Presumably, you then get the benefits of both.

This isn't really the ability to "save" your files as DocBook XML.  It's
actually just an "export" feature, with no corresponding feature to
"import" from DocBook XML.  If you use this, you'll have to maintain
your document in OOo format, and export to DocBook XML format.  I'm not
sure how well this will track changes across versions.
	Greg

This is a digitally signed message part



> Hi,
> 
> I'm new to DocBook. As far as I know there is a DocBook 
> version based on
> XML. I know OpenOffice.org a little bit which is based on 
> XML, too, and thus can
> be transformed to many other formats. Can you tell me what 
> would be the
> advantages of using DocBook instead of OpenOffice.org? What 
> the disadvantages?

Hi Florian,

there's another project for OpenOffice to DocBook export:

http://www.chez.com/ebellot/ooo2sdbk/

But, as Gregory Leblanc already mentioned, you'll have to maintain
your document in OOo format, and export it to DocBook XML format. At this
point, all export tools have several limitations.

What format you choose for your work depends completely on the purpose. E.g.
you won't probably write a spreadsheet in DocBook or, on the other hand a
documentation needed as PDF and HTML Help with OpenOffice.

Regards
Gisbert Amm



On Sat, Mar 01, 2003 at 08:33:05PM +0300, Alexander Voropay wrote:
> Is seems, this file isn't copyrigted, so you could use it as you
> want.

Hm.  IIRC if there is no explicit statement that you can use it as you
like, by default you can't legally do anything with it...

-- 
Yann Dirson <Yann.Dirson@fr.alcove.com>                 http://www.alcove.com/
Technical support manager                Responsable de l'assistance technique
Senior Free-Software Consultant          Consultant senior en Logiciels Libres
Debian developer (dirson@debian.org)                        Développeur Debian



Hi

Is there a DocBook XML schema (eg DTD or RNG) featuring XHTML tables?
(perhaps some OASIS draft)

What's the plan; will DocBook incorporate XHTML tables in its namespace, 
or will it have an XHTML Table Module where the elements are in the 
XHTML namespace? Which version of DocBook will feature XHTML tables? (if 
any)

Tobi

-- 
http://www.pinkjuice.com/




Hi

What would be the shortes/easiest way to specify a subset of DocBook XML 
which excludes CALS tables?

Tobi

-- 
http://www.pinkjuice.com/




Bob Stayton wrote:


> The DocBook Technical Committee has been discussing this
> for several recent meetings.  At this point the committee
> is not supporting HTML tables in DocBook, for the reasons
> described in the last set of minutes[1].  It will be
> considered again in the next meeting on 18 March.
> 
> [1] http://lists.oasis-open.org/archives/docbook-tc/200301/msg00015.html


"Norm: If we were starting over, I don't think there'd be much support 
for CALS over HTML."

I agree. I think I'd be much happier with a DocBook which includes the 
XHTML table model. Simple to write, simple to process, familiar to many.
(Perhaps you could forward this vote to the TC :)

Tobi


-- 
http://www.pinkjuice.com/




Bob Stayton wrote:


> Create a DTD customization layer that sets:
> 
> <!ENTITY % cals.table.module "IGNORE">


That's how far I got already :)
Seriously though: thanks for your reply.


> See DocBook: The Definitive Guide for help creating a DTD
> customization layer.


Yeah, I glanced over it. I just wanted to ask here, since I thought that 
someone might already have code what I want :)


> If you are planning to replace <table> with something else,
> then you also need to include those declarations.
> 
> If your intent is to eliminate <table> completely, then
> you will need to modify this parameter entity as well
> to remove 'table':
> 
> <!ENTITY % formal.class
> 		"equation|example|figure|table %local.formal.class;">
> 
> If you plan to paste in the XHTML table element
> declarations, be aware that you also need to add the
> XHTML elements listed in their content models, or rewrite
> the content models to contain only DocBook elements. 


I think I'd like to disallow CALS, then allow for XHTML table elements 
table, tr, td, etc, and allow for para, inline stuff, etc inside td; but 
I'm not sure yet.

I'm really looking forward to seeing an XHTML table module incorporated 
into full and official DocBook ...


Tobi


-- 
http://www.pinkjuice.com/




At 21:46 2003 03 03 +0100, Tobias Reif wrote:
>Bob Stayton wrote:
>
>
>>Create a DTD customization layer that sets:
>><!ENTITY % cals.table.module "IGNORE">
>
>
>That's how far I got already :)
>Seriously though: thanks for your reply.
>
>
>>See DocBook: The Definitive Guide for help creating a DTD
>>customization layer.
>
>
>Yeah, I glanced over it. I just wanted to ask here, since I thought that someone might already have code what I want :)
>
>
>>If you are planning to replace <table> with something else,
>>then you also need to include those declarations.
>>If your intent is to eliminate <table> completely, then
>>you will need to modify this parameter entity as well
>>to remove 'table':
>><!ENTITY % formal.class
>>                "equation|example|figure|table %local.formal.class;">
>>If you plan to paste in the XHTML table element
>>declarations, be aware that you also need to add the
>>XHTML elements listed in their content models, or rewrite
>>the content models to contain only DocBook elements. 
>
>
>I think I'd like to disallow CALS, then allow for XHTML table elements table, tr, td, etc, and allow for para, inline stuff, etc inside td; but I'm not sure yet.


By doing this, you're making incompatible subsets.
This worries me.

I think the right answer is to have DocBook augment
the DTD so that both CALS and HTML tables are allowed.
Then we avoid the incompatible subset issue, existing
users can continue to use CALS, others can use HTML,
and you can even mix a CALS table and an HTML table
in the same document.

(This issue was discussed in the TC, and the rest of
the TC disagreed with me here, but the fact that users
are now pushing to make incompatible subsets raises
my concerns even more.)

paul





Paul Grosso wrote:

 >> I think I'd like to disallow CALS, then allow for XHTML table
 >> elements table, tr, td, etc, and allow for para, inline stuff,
 >> etc inside td; but I'm not sure yet.
 >>
 > By doing this, you're making incompatible subsets. This worries me.

It should, but there are two separate things being discussed.

If I create an extended version of DocBook (not a proper subset, just 
shares an intersection), then this has the obvious drawbacks of 
extending languages locally; (other) tools won't know what to expect 
etc. It would be a desparate workaround, a (hopefully) temporary hack.

As I wrote, the solution I want is to see the XHTML table model in the 
official DocBook language/schmema (DTD).
The CALS table model could be kept for forwards-compatibility of older 
content, or it could be dropped if there ever will be a non-compatible 
major version, eg DocBook 5.

Elements are being added to DocBook with each version, AFAICS. The XHTML 
table model could be added as well. It could be in it's own namespace, 
or in DocBook's.

 > I think the right answer is to have DocBook augment the DTD so that
 > both CALS and HTML tables are allowed.

Fine with me!

(To clarify:
In thread "XHTML tables" I wrote
"I think I'd be much happier with a DocBook which includes the XHTML 
table model.", and didn't request exclusion of CALS.
In the other thread I was talking about a local custom DTD for 
experimental purposes (processing DocBook+XHTMLTables), where I do want 
to disallow the use of CALS tables. (this would be a proper subset of a 
hypothetical future DocBook+XHTMLTables))

 > Then we avoid the
 > incompatible subset issue, existing users can continue to use CALS,
 >  others can use HTML,

Sounds great! I really hope to see this in an official final DTD soon. 
Then, regarding my DocBook to XHTML tool Doxy [1], I could simply write 
"CALS tables are not supported, use XHTML tables", without ever having 
to mess with some unofficial homegrown schema (DTD) (except perhaps one 
that defines a proper subset).

And the code would be infinitely simpler than CALS to HTML code ;)
(just copy the elements with their attributes)

 > and you can even mix a CALS table and an HTML
 >  table in the same document.

Nothing is too far out to be done by some, but I don't think I'd want to 
do that :)
Put differently; I could live without this. (mixing both models in one 
table)

 > (This issue was discussed in the TC, and the rest of the TC
 > disagreed with me here, but the fact that users are now pushing to
 > make incompatible subsets raises my concerns even more.)

Simply include the XHTML table model in the next version of DoocBook, 
and most will be happy I think :)

P.S.
Excluding CALS tables in some future version would have one advantage:
New tools could support 100% DocBook (including tables etc) without 
having to deal with the complex CALS table model.

P.P.S.
On Wed Oct 17 2001 Eve L. Maler wrote
"I think DocBook should begin to allow HTML tables anyway..." [2]
and Norm replied
"Yeah. I think I'd be in favor of that, [...]" [3]
Later, Tim Bray said
"And I'm sorry, CALS tables are *right out*.  Don't go there." [4]

Tobi

[1]
http://www.pinkjuice.com/doxy/
[2]
http://lists.w3.org/Archives/Public/spec-prod/2001OctDec/0021.html
[3]
http://lists.w3.org/Archives/Public/spec-prod/2001OctDec/0024.html
[4]
http://lists.w3.org/Archives/Public/spec-prod/2001OctDec/0027.html

-- 
http://www.pinkjuice.com/




At 22:52 2003 03 03 +0100, Tobias Reif wrote:
>Paul Grosso wrote:
>
>>> I think I'd like to disallow CALS, then allow for XHTML table
>>> elements table, tr, td, etc, and allow for para, inline stuff,
>>> etc inside td; but I'm not sure yet.
>>>
>> By doing this, you're making incompatible subsets. This worries me.
>
>It should, but there are two separate things being discussed.
>
>If I create an extended version of DocBook (not a proper subset, just shares an intersection), then this has the obvious drawbacks of extending languages locally; (other) tools won't know what to expect etc. It would be a desparate workaround, a (hopefully) temporary hack.
>
>As I wrote, the solution I want is to see the XHTML table model in the official DocBook language/schmema (DTD).
>The CALS table model could be kept for forwards-compatibility of older content, or it could be dropped if there ever will be a non-compatible major version, eg DocBook 5.
>
>Elements are being added to DocBook with each version, AFAICS. The XHTML table model could be added as well. It could be in it's own namespace, or in DocBook's.

I agree.  But the TC just decided against this.

>> I think the right answer is to have DocBook augment the DTD so that
>> both CALS and HTML tables are allowed.
>
>Fine with me!
>
>(To clarify:
>In thread "XHTML tables" I wrote
>"I think I'd be much happier with a DocBook which includes the XHTML table model.", and didn't request exclusion of CALS.
>In the other thread I was talking about a local custom DTD for experimental purposes (processing DocBook+XHTMLTables), where I do want to disallow the use of CALS tables. (this would be a proper subset of a hypothetical future DocBook+XHTMLTables))
>
>> Then we avoid the
>> incompatible subset issue, existing users can continue to use CALS,
>>  others can use HTML,
>
>Sounds great! I really hope to see this in an official final DTD soon. Then, regarding my DocBook to XHTML tool Doxy [1], I could simply write "CALS tables are not supported, use XHTML tables", without ever having to mess with some unofficial homegrown schema (DTD) (except perhaps one that defines a proper subset).
>
>And the code would be infinitely simpler than CALS to HTML code ;)
>(just copy the elements with their attributes)
>
>> and you can even mix a CALS table and an HTML
>>  table in the same document.
>
>Nothing is too far out to be done by some, but I don't think I'd want to do that :)
>Put differently; I could live without this. (mixing both models in one table)
>
>> (This issue was discussed in the TC, and the rest of the TC
>> disagreed with me here, but the fact that users are now pushing to
>> make incompatible subsets raises my concerns even more.)
>
>Simply include the XHTML table model in the next version of DoocBook, and most will be happy I think :)

But "including the XHTML table model" while not removing the CALS 
table model and still only having one DocBook DTD implies allowing
both kinds of tables in a document.  Which is just what I was
suggesting but that didn't make it through the TC.  So as things
stand now, it's not going to happen.

>P.S.
>Excluding CALS tables in some future version would have one advantage:
>New tools could support 100% DocBook (including tables etc) without having to deal with the complex CALS table model.

That's not an advantage for users, especially those with existing
docbook documents!  While I appreciate your point about tools and
implementors (I'm an implementor too), it is generally more important
to make users life easier, not implementor's lives.  That's why I
think we should allow both kinds of tables.

paul




Paul Grosso wrote:
 >> The
 >> XHTML table model could be added as well. It could be in it's
 >> own namespace, or in DocBook's.
 >>
 > I agree.  But the TC just decided against this.

You mean right now? Minutes ago? This is sad news.

 > But "including the XHTML table model" while not removing the CALS
 > table
 >  model and still only having one DocBook DTD implies allowing both
 > kinds of tables in a document.

Sorry, I thought you were talking about mixing both model's elements in 
one table.

 > Which is just what I was suggesting
 >  but that didn't make it through the TC.  So as things stand now,
 > it's not going to happen.

Will the reasons/arguments be published?

 >> P.S. Excluding CALS tables in some future version would have one
 >> advantage: New tools could support 100% DocBook (including tables
 >>  etc) without having to deal with the complex CALS table model.
 >>
 > That's not an advantage for users, especially those with existing
 > docbook
 >  documents!

I'm aware of the fact that it would be a disadvantage for people with 
DocBook documents using CALS tables. But in the lifetime of a language, 
there can be cuts.
Process old content with old tools, or update old content (via some 
tool, but this could be lossy), process new content with new tools. But 
anyways, I don't think that CALS tables *must* be removed. People can 
disallow them locally (by subsetting the schema).

 > While I appreciate your point about tools and implementors
 >  (I'm an implementor too), it is generally more important to make
 > users life easier, not implementor's lives.  That's why I think we
 > should allow both kinds of tables.

OK, so there are at least four people in favour of adding XHTML tables 
to DocBook:
You, me, Norm (I think), Eve Maler, probably many more. What can we do? 
Simply publish DocBook+XHTMLTables? Simply use them, since they are in 
their own namespace? Write an XSLT transforming DocBook+XHTMLTables to 
DocBook(+CALSTables)?
The latter would allow people to author using simple XHTML tables, but 
feed CALS to validators and transformers. This translation could be 
(nearly) lossless, AFAICS.

Tobi

-- 
http://www.pinkjuice.com/

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Powered by ezmlm-idx