You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Ivelin Ivanov <iv...@apache.org> on 2002/06/01 15:51:27 UTC

DocBook vs Open eBook

Does someone know the difference between these two standards initiatives:
http://www.oasis-open.org/committees/docbook/
http://www.oasis-open.org/cover/openEbook.html

They both seem to have industry backing while at the same time overlap quite
a bit.

Also, why don't we use one of these two for our documentation instead of
maintaining proprietary DTDs. There are tools on the market for WYWIWYG
editing of both of these standards, which can make doc writing easier. And
of course there are XLSTs for rendering to media from XHTML to voxml to PDF.

Regards,

Ivelin



---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org


RE: DocBook vs Open eBook

Posted by Steven Noels <st...@outerthought.org>.
> From: Ivelin Ivanov [mailto:ivelin@apache.org]

<quote>
> I certainly don't want to slow down the forrest contributions
> which just picked up momentum.
</quote>

<quote>
> Obviously I don't have enough experience with maintaining Cocoon
> documentation and I am not even a contributor to Forrest, so all my
> suggestions have little merit, compared to the people that
> actually commit
> docs.
</quote>

Obviously you are not aware of the fact people get bashed over here for
other reasons as well, i.e. minimalizing the value of their own
contributions based on comments or remarks... ;-)

Ivelin, we value your comments, remarks, etc... we need people like you
over here to thrown in new ideas. Your judgement of the merits of your
contributions is simply incorrect. I agree this is mostly a developer's
community and not so much a user's, but please keep on nagging us.

We'll follow up on them as time permits, but sure they are appreciated!

</Steven>


Re: DocBook vs Open eBook

Posted by Ivelin Ivanov <iv...@apache.org>.
Good to know your opinion Stefano.


Obviously I don't have enough experience with maintaining Cocoon
documentation and I am not even a contributor to Forrest, so all my
suggestions have little merit, compared to the people that actually commit
docs.

DocBook has been bashed by other people as well.

Open eBook is using the Dublin Core standard as well as many XHTML tags.
It's intention is to allow authors to use markup which can be then rendered
on different devices, from PDAs to PCs to print. Some browsers will use all
the markup some will ignore it partially. The spec has guidelines for this.

Anyhow, I hate to distract people who are working hard to get Forrest going,
so I guess we can pick up this discussion later.

I agree that this is FAQ though, are you submitting your thoughts to Diana
for addition in the docs?


Ivelin





----- Original Message -----
From: "Stefano Mazzocchi" <st...@apache.org>
To: <co...@xml.apache.org>
Cc: <fo...@xml.apache.org>
Sent: Monday, June 03, 2002 4:21 AM
Subject: Re: DocBook vs Open eBook


> Ivelin Ivanov wrote:
> >
> > Does someone know the difference between these two standards
initiatives:
> > http://www.oasis-open.org/committees/docbook/
> > http://www.oasis-open.org/cover/openEbook.html
> >
> > They both seem to have industry backing while at the same time overlap
quite
> > a bit.
> >
> > Also, why don't we use one of these two for our documentation instead of
> > maintaining proprietary DTDs. There are tools on the market for WYWIWYG
> > editing of both of these standards, which can make doc writing easier.
And
> > of course there are XLSTs for rendering to media from XHTML to voxml to
PDF.
> >
> > Regards,
>
> > Ivelin
>
> Ivelin,
>
> this is a FAQ. big time FAQ, I might say. And also, it's totally
> off-topic on the cocoon-dev list since forrest was created also to
> manage the DTD of the xml.apache.org documentation (well, attempt to).
>
> Anyway, in one word: both docbook/openebook are more complex that what
> we need. We need to adapt the stylesheets anyway and the editing tools
> are focusing on a XML/CSS solution (not toward a hardcoded WYSIWYG
> experience) see XEE as an example.
>
> Finally, our DTD reuses HTML tagnames were possible.
>
> I hate this DTD debate because it becomes religious at some point, but
> my point is: proceed incrementally. In two years, this community (now
> handed over to forrest's) has managed the DTD in quite a successful
> manner. Very few changes were required, yet the documentation is pretty
> solid and complete in functionality.
>
> Docbook simply tries to be too many things at the same time, but mostly
> is a markup for books or collection of books. openebook is also a markup
> for books.
>
> The docbook stylesheets are so complex that there is a project to
> maintain them. Look at how easy (compared to the docbook stylesheets) it
> is to create a forrest skin.
>
> Would you want to impose the overhead of creating a skin for all the
> docbook/openebook tags on the skin authors?
>
> You might say: let's use only a subset (like almost everybody does), but
> then you are not using Docbook, but a proprietary subset of docbook (and
> maybe we ended up needing a feature that docbook doesn't have, so we are
> using an 'extended subset' of docbook).
>
> In short, I fear we'll end up not using docbook anyway.
>
> So, in the good old software darwinism patter: let's the DTD evolve with
> us. We already need the ability to include authoring metadata and we
> might use the dublin-core namespace for this. Docbook doesn't allow this
> (yet).
>
> Bah, I see almost no value in going standard with markup when we don't
> need to 'interoperate' with anybody and there is almost nothing we can
> reuse from the environments where more standard markup is used.
>
> --
> Stefano Mazzocchi      One must still have chaos in oneself to be
>                           able to give birth to a dancing star.
> <st...@apache.org>                             Friedrich Nietzsche
> --------------------------------------------------------------------
>
>


Re: DocBook vs Open eBook

Posted by Stefano Mazzocchi <st...@apache.org>.
Ivelin Ivanov wrote:
> 
> Does someone know the difference between these two standards initiatives:
> http://www.oasis-open.org/committees/docbook/
> http://www.oasis-open.org/cover/openEbook.html
> 
> They both seem to have industry backing while at the same time overlap quite
> a bit.
> 
> Also, why don't we use one of these two for our documentation instead of
> maintaining proprietary DTDs. There are tools on the market for WYWIWYG
> editing of both of these standards, which can make doc writing easier. And
> of course there are XLSTs for rendering to media from XHTML to voxml to PDF.
> 
> Regards,

> Ivelin

Ivelin,

this is a FAQ. big time FAQ, I might say. And also, it's totally
off-topic on the cocoon-dev list since forrest was created also to
manage the DTD of the xml.apache.org documentation (well, attempt to).

Anyway, in one word: both docbook/openebook are more complex that what
we need. We need to adapt the stylesheets anyway and the editing tools
are focusing on a XML/CSS solution (not toward a hardcoded WYSIWYG
experience) see XEE as an example.

Finally, our DTD reuses HTML tagnames were possible.

I hate this DTD debate because it becomes religious at some point, but
my point is: proceed incrementally. In two years, this community (now
handed over to forrest's) has managed the DTD in quite a successful
manner. Very few changes were required, yet the documentation is pretty
solid and complete in functionality.

Docbook simply tries to be too many things at the same time, but mostly
is a markup for books or collection of books. openebook is also a markup
for books.

The docbook stylesheets are so complex that there is a project to
maintain them. Look at how easy (compared to the docbook stylesheets) it
is to create a forrest skin. 

Would you want to impose the overhead of creating a skin for all the
docbook/openebook tags on the skin authors?

You might say: let's use only a subset (like almost everybody does), but
then you are not using Docbook, but a proprietary subset of docbook (and
maybe we ended up needing a feature that docbook doesn't have, so we are
using an 'extended subset' of docbook).

In short, I fear we'll end up not using docbook anyway.

So, in the good old software darwinism patter: let's the DTD evolve with
us. We already need the ability to include authoring metadata and we
might use the dublin-core namespace for this. Docbook doesn't allow this
(yet).

Bah, I see almost no value in going standard with markup when we don't
need to 'interoperate' with anybody and there is almost nothing we can
reuse from the environments where more standard markup is used.

-- 
Stefano Mazzocchi      One must still have chaos in oneself to be
                          able to give birth to a dancing star.
<st...@apache.org>                             Friedrich Nietzsche
--------------------------------------------------------------------



---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org


Re: DocBook vs Open eBook

Posted by Ivelin Ivanov <iv...@apache.org>.
DocBook was pretty much ruled out by Rob.

Let's talk about Open eBook.

Any reason why we shouldn't adopt it?

Ivelin


----- Original Message ----- 
From: "Bernhard Huber" <be...@a1.net>
To: <co...@xml.apache.org>
Sent: Sunday, June 02, 2002 11:17 AM
Subject: Re: DocBook vs Open eBook


> Hi
> I think the reason for using Apache DTD is more historic, as at the 
> beginning
> the DocBook was not that much mature.
> Moreover think about that the Docbook DTD is more complicate, and
> it may take a bit longer to start using it.
> Neither of these arguments stops from switching to the Docbook DTD.
> bye bernhard
> 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org


Re: DocBook vs Open eBook

Posted by Ivelin Ivanov <iv...@apache.org>.
Steven,

I certainly don't want to slow down the forrest contributions which just
picked up momentum.


However Open eBook is a standard we should keep a close eye on and be ready
to work with it sooner than later.


Your suggestion to provide transformers to open ebook sounds good, although
it shouldn't be top priority for forrest, yet. It might be in the near
future.


Cheers,

Ivelin


----- Original Message -----
From: "Steven Noels" <st...@outerthought.org>
To: <co...@xml.apache.org>
Cc: <fo...@xml.apache.org>
Sent: Tuesday, June 04, 2002 7:35 AM
Subject: RE: DocBook vs Open eBook


> > From: Ivelin Ivanov [mailto:ivelin@apache.org]
>
> > So do you have preferences between Open eBook and simplified DocBook?
>
> Ivelin,
>
> sorry for not following up rightaway.
>
> I believe we should stick to what we have now for the time being, i.e.
> document-v11 and others being readied by Diana, David, myself and others
> in between Forrest and Cocoon. These are simple grammars which a
> significant share of contributors already know, and the investment of
> learning to use them being minimal.
>
> I am kind of interested in the Open eBook stuff as being a delivery
> grammar, not an authoring grammar, just as (X)HTML for webbrowsers and
> FO for print documentation.
>
> Does anyone on these lists has access to an eBook reader - the hardware,
> I mean, not the Microsoft/Adobe software products.
>
> Setting up a conversion from what we have as a source format to eBook
> format is trivial, and we could include this into Forrest given interest
> from both information producers and information consumers. Manning
> already offers some Java/XML books in eBook format, I don't see why we
> can't do that, too.
>
> What do you think?
>
> </Steven>
>


Re: DocBook vs Open eBook

Posted by Ivelin Ivanov <iv...@apache.org>.

Another cool feature I'd like to stress out again is the ability to use
references defined in the manifest from within the book. That helps with the
problem of duplicating absolute links all over the place.


Ivelin

----- Original Message -----
From: "Nicola Ken Barozzi" <ni...@apache.org>
To: <fo...@xml.apache.org>
Sent: Tuesday, June 04, 2002 1:02 PM
Subject: Re: DocBook vs Open eBook


From: "Steven Noels" <st...@outerthought.org>

> I am kind of interested in the Open eBook stuff as being a delivery
> grammar, not an authoring grammar, just as (X)HTML for webbrowsers and
> FO for print documentation.
>
> Does anyone on these lists has access to an eBook reader - the hardware,
> I mean, not the Microsoft/Adobe software products.
>
> Setting up a conversion from what we have as a source format to eBook
> format is trivial, and we could include this into Forrest given interest
> from both information producers and information consumers. Manning
> already offers some Java/XML books in eBook format, I don't see why we
> can't do that, too.

I've read the specification, and it's basically a cleaned HTML (trying to
use more CSS) with a kind of book.xml (called spine).
It seems geared towards presentation, while we want to try and use tags with
meaning, instead of style.

So I'm totally with Steven's POV: ebook is not for us, but it's really cool
as an output format, which could be supported in the future.

Anyway, it has interesting points in the descriptors that it uses.
Take particular notice of the Spine and the Tour, which seem very cool.

Book Metadata
------------------
example:
<package unique-identifier="xyz">
<metadata>
  <dc-metadata xmlns:dc="http://purl.org/dc/elements/1.0/"
     xmlns:oebpackage="http://openebook.org/namespaces/oeb-package/1.0/">
    <dc:Title>Alice in Wonderland</dc:Title>
    <dc:Type>Novel</dc:Type>
    <dc:Identifier id="xyz"
       scheme="ISBN">123456789X</dc:Identifier>
    <dc:Creator role="aut">Lewis Carroll</dc:Creator>
  </dc-metadata>
</metadata>
...
</package>


A Manifest of the pubblication
-----------------------------------------
The manifest provides a list of all the files that are parts of the
publication.

<manifest>
<item id="item1"
   href="FunDoc.txt"
   media-type="text/plain"
   fallback="fall1" />
<item id="fall1" fallback="fall2"
   href="FunDoc.html"
   media-type="text/html" />
<item id="fall2"
   href="FunDoc.oeb"
   media-type="text/x-oeb1-document" />
<item ...>
</manifest>

A Spine
------------
Following the manifest, there must be one spine element, which defines a
primary linear reading order of the publication. It specifies an ordered
list of one or more OEB documents
drawn from the manifest, using itemref elements contained within the spine
element.

<manifest>
<item id="toc"
   href="contents.html"
   media-type="text/x-oeb1-document" />
<item id="c1"
   href="chap1.html"
   media-type="text/x-oeb1-document" />
<item id="c2"
   href="chap2.html"
   media-type="text/x-oeb1-document" />
<item id="c3"
   href="chap3.html"
   media-type="text/x-oeb1-document" />
<item id="footnotes"
   href="footnotes.html"
   media-type="text/x-oeb1-document" />
<item id="f1" href="fig1.jpg" media-type="image/jpeg" />
<item id="f2" href="fig2.jpg" media-type="image/jpeg" />
<item id="f3" href="fig3.jpg" media-type="image/jpeg" />
</manifest>

<spine>
<itemref idref="toc" />
<itemref idref="c1" />
<itemref idref="c2" />
<itemref idref="c3" />
</spine>

Tours
---------
Much as a tour-guide might assemble points of interest into a set of
sightseers’ tours, a content provider may assemble selected parts of a
publication into a set of tours to enable convenient navigation.

<tours>
<tour id="tour1" title="Chicken Recipes">
  <site title="Chicken Fingers"   href="appetizers.html#r3" />
  <site title="Chicken a la King" href="entrees.html#r5" />
</tour>
<tour id="tour2" title="Vegan Recipes">
  <site title="Hummus" href ="appetizer.html#r6" />
  <site title="Lentil Casserole" href="lentils.html" />
</tour>
</tours>

2.6 Guide
Within the package there may be one guide element, containing one or more
reference
elements. The guide element identifies fundamental structural components of
the publication,
to enable reading systems to provide convenient access to them.
Example:

<guide>
<reference type="toc" title="Table of Contents" href="toc.html" />
<reference type="loi" title="List Of Illustrations" href="toc.html#figures"
/>
<reference type="other.intro" title="Introduction" href="intro.html" />
</guide>

--
Nicola Ken Barozzi                   nicolaken@apache.org
            - verba volant, scripta manent -
   (discussions get forgotten, just code remains)
---------------------------------------------------------------------



Re: DocBook vs Open eBook

Posted by Nicola Ken Barozzi <ni...@apache.org>.
From: "Steven Noels" <st...@outerthought.org>

> I am kind of interested in the Open eBook stuff as being a delivery
> grammar, not an authoring grammar, just as (X)HTML for webbrowsers and
> FO for print documentation.
>
> Does anyone on these lists has access to an eBook reader - the hardware,
> I mean, not the Microsoft/Adobe software products.
>
> Setting up a conversion from what we have as a source format to eBook
> format is trivial, and we could include this into Forrest given interest
> from both information producers and information consumers. Manning
> already offers some Java/XML books in eBook format, I don't see why we
> can't do that, too.

I've read the specification, and it's basically a cleaned HTML (trying to
use more CSS) with a kind of book.xml (called spine).
It seems geared towards presentation, while we want to try and use tags with
meaning, instead of style.

So I'm totally with Steven's POV: ebook is not for us, but it's really cool
as an output format, which could be supported in the future.

Anyway, it has interesting points in the descriptors that it uses.
Take particular notice of the Spine and the Tour, which seem very cool.

Book Metadata
------------------
example:
<package unique-identifier="xyz">
<metadata>
  <dc-metadata xmlns:dc="http://purl.org/dc/elements/1.0/"
     xmlns:oebpackage="http://openebook.org/namespaces/oeb-package/1.0/">
    <dc:Title>Alice in Wonderland</dc:Title>
    <dc:Type>Novel</dc:Type>
    <dc:Identifier id="xyz"
       scheme="ISBN">123456789X</dc:Identifier>
    <dc:Creator role="aut">Lewis Carroll</dc:Creator>
  </dc-metadata>
</metadata>
...
</package>


A Manifest of the pubblication
-----------------------------------------
The manifest provides a list of all the files that are parts of the
publication.

<manifest>
<item id="item1"
   href="FunDoc.txt"
   media-type="text/plain"
   fallback="fall1" />
<item id="fall1" fallback="fall2"
   href="FunDoc.html"
   media-type="text/html" />
<item id="fall2"
   href="FunDoc.oeb"
   media-type="text/x-oeb1-document" />
<item ...>
</manifest>

A Spine
------------
Following the manifest, there must be one spine element, which defines a
primary linear reading order of the publication. It specifies an ordered
list of one or more OEB documents
drawn from the manifest, using itemref elements contained within the spine
element.

<manifest>
<item id="toc"
   href="contents.html"
   media-type="text/x-oeb1-document" />
<item id="c1"
   href="chap1.html"
   media-type="text/x-oeb1-document" />
<item id="c2"
   href="chap2.html"
   media-type="text/x-oeb1-document" />
<item id="c3"
   href="chap3.html"
   media-type="text/x-oeb1-document" />
<item id="footnotes"
   href="footnotes.html"
   media-type="text/x-oeb1-document" />
<item id="f1" href="fig1.jpg" media-type="image/jpeg" />
<item id="f2" href="fig2.jpg" media-type="image/jpeg" />
<item id="f3" href="fig3.jpg" media-type="image/jpeg" />
</manifest>

<spine>
<itemref idref="toc" />
<itemref idref="c1" />
<itemref idref="c2" />
<itemref idref="c3" />
</spine>

Tours
---------
Much as a tour-guide might assemble points of interest into a set of
sightseers’ tours, a content provider may assemble selected parts of a
publication into a set of tours to enable convenient navigation.

<tours>
<tour id="tour1" title="Chicken Recipes">
  <site title="Chicken Fingers"   href="appetizers.html#r3" />
  <site title="Chicken a la King" href="entrees.html#r5" />
</tour>
<tour id="tour2" title="Vegan Recipes">
  <site title="Hummus" href ="appetizer.html#r6" />
  <site title="Lentil Casserole" href="lentils.html" />
</tour>
</tours>

2.6 Guide
Within the package there may be one guide element, containing one or more
reference
elements. The guide element identifies fundamental structural components of
the publication,
to enable reading systems to provide convenient access to them.
Example:

<guide>
<reference type="toc" title="Table of Contents" href="toc.html" />
<reference type="loi" title="List Of Illustrations" href="toc.html#figures"
/>
<reference type="other.intro" title="Introduction" href="intro.html" />
</guide>

--
Nicola Ken Barozzi                   nicolaken@apache.org
            - verba volant, scripta manent -
   (discussions get forgotten, just code remains)
---------------------------------------------------------------------


RE: DocBook vs Open eBook

Posted by Steven Noels <st...@outerthought.org>.
> From: Ivelin Ivanov [mailto:ivelin@apache.org]

> So do you have preferences between Open eBook and simplified DocBook?

Ivelin,

sorry for not following up rightaway.

I believe we should stick to what we have now for the time being, i.e.
document-v11 and others being readied by Diana, David, myself and others
in between Forrest and Cocoon. These are simple grammars which a
significant share of contributors already know, and the investment of
learning to use them being minimal.

I am kind of interested in the Open eBook stuff as being a delivery
grammar, not an authoring grammar, just as (X)HTML for webbrowsers and
FO for print documentation.

Does anyone on these lists has access to an eBook reader - the hardware,
I mean, not the Microsoft/Adobe software products.

Setting up a conversion from what we have as a source format to eBook
format is trivial, and we could include this into Forrest given interest
from both information producers and information consumers. Manning
already offers some Java/XML books in eBook format, I don't see why we
can't do that, too.

What do you think?

</Steven>


---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org


RE: DocBook vs Open eBook

Posted by Steven Noels <st...@outerthought.org>.
> From: Ivelin Ivanov [mailto:ivelin@apache.org]

> So do you have preferences between Open eBook and simplified DocBook?

Ivelin,

sorry for not following up rightaway.

I believe we should stick to what we have now for the time being, i.e.
document-v11 and others being readied by Diana, David, myself and others
in between Forrest and Cocoon. These are simple grammars which a
significant share of contributors already know, and the investment of
learning to use them being minimal.

I am kind of interested in the Open eBook stuff as being a delivery
grammar, not an authoring grammar, just as (X)HTML for webbrowsers and
FO for print documentation.

Does anyone on these lists has access to an eBook reader - the hardware,
I mean, not the Microsoft/Adobe software products.

Setting up a conversion from what we have as a source format to eBook
format is trivial, and we could include this into Forrest given interest
from both information producers and information consumers. Manning
already offers some Java/XML books in eBook format, I don't see why we
can't do that, too.

What do you think?

</Steven>


RE: DocBook vs Open eBook

Posted by Conal Tuohy <co...@paradise.net.nz>.
DocBook and Simplified DocBook are for technical documentation, and in
particular for documenting software. Not just books, but also articles,
"white papers" etc. Open eBook, as far as I understand it (I'm not really
familiar with it), is for books, and not for technical books in particular,
let alone books about software.

BTW, I've written two software manuals in SDBk (which is well-documented on
the web), so for me personally it would be easier to write than using the
Cocoon documentation DTDs. But so long as the Cocoon DTDs are themselves
well-documented I don't really care. In fact, for such a collaborative
situation, I'm sure it's better to have a small set of very simple DTDs so
that anyone can quickly write a "recipe" for the community. But then the
meta-documentation (how to write a "recipe") is also essential if people are
going to write docs for Cocoon: otherwise the Cocoon doc formats will just
hold people back from writing! ;-)

Con

> -----Original Message-----
> From: Ivelin Ivanov [mailto:ivelin@apache.org]
> Sent: Wednesday, 5 June 2002 00:26
> To: cocoon-dev@xml.apache.org
> Subject: Re: DocBook vs Open eBook
>
>
>
> So do you have preferences between Open eBook and simplified DocBook?
>
>
> ----- Original Message -----
> From: "Conal Tuohy" <co...@paradise.net.nz>
> To: <co...@xml.apache.org>
> Sent: Monday, June 03, 2002 1:01 AM
> Subject: RE: DocBook vs Open eBook
>
>
> > > -----Original Message-----
> > > From: Bernhard Huber [mailto:berni_huber@a1.net]
> > > Sent: Monday, 3 June 2002 04:18
> > > To: cocoon-dev@xml.apache.org
> > > Subject: Re: DocBook vs Open eBook
> > >
> > >
> > > Hi
> > > I think the reason for using Apache DTD is more historic,
> as at the
> > > beginning
> > > the DocBook was not that much mature.
> > > Moreover think about that the Docbook DTD is more complicate, and
> > > it may take a bit longer to start using it.
> > > Neither of these arguments stops from switching to the
> Docbook DTD.
> > > bye bernhard
> >
> > DocBook IS very complicated (hundreds of elements). But
> there is a doctype
> > called "Simplified DocBook" which is a subset of the full
> DocBook. I've
> used
> > it myself; It's not very complicated at all, but I think it
> is probably
> rich
> > enough.
> >
> > http://www.docbook.org/xml/simple/index.html
> >
> >
> >
> ---------------------------------------------------------------------
> > To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> > For additional commands, email: cocoon-dev-help@xml.apache.org
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org
>
>


---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org


Re: DocBook vs Open eBook

Posted by Ivelin Ivanov <iv...@apache.org>.
So do you have preferences between Open eBook and simplified DocBook?


----- Original Message -----
From: "Conal Tuohy" <co...@paradise.net.nz>
To: <co...@xml.apache.org>
Sent: Monday, June 03, 2002 1:01 AM
Subject: RE: DocBook vs Open eBook


> > -----Original Message-----
> > From: Bernhard Huber [mailto:berni_huber@a1.net]
> > Sent: Monday, 3 June 2002 04:18
> > To: cocoon-dev@xml.apache.org
> > Subject: Re: DocBook vs Open eBook
> >
> >
> > Hi
> > I think the reason for using Apache DTD is more historic, as at the
> > beginning
> > the DocBook was not that much mature.
> > Moreover think about that the Docbook DTD is more complicate, and
> > it may take a bit longer to start using it.
> > Neither of these arguments stops from switching to the Docbook DTD.
> > bye bernhard
>
> DocBook IS very complicated (hundreds of elements). But there is a doctype
> called "Simplified DocBook" which is a subset of the full DocBook. I've
used
> it myself; It's not very complicated at all, but I think it is probably
rich
> enough.
>
> http://www.docbook.org/xml/simple/index.html
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org
>


---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org


RE: DocBook vs Open eBook

Posted by Conal Tuohy <co...@paradise.net.nz>.
> -----Original Message-----
> From: Bernhard Huber [mailto:berni_huber@a1.net]
> Sent: Monday, 3 June 2002 04:18
> To: cocoon-dev@xml.apache.org
> Subject: Re: DocBook vs Open eBook
>
>
> Hi
> I think the reason for using Apache DTD is more historic, as at the
> beginning
> the DocBook was not that much mature.
> Moreover think about that the Docbook DTD is more complicate, and
> it may take a bit longer to start using it.
> Neither of these arguments stops from switching to the Docbook DTD.
> bye bernhard

DocBook IS very complicated (hundreds of elements). But there is a doctype
called "Simplified DocBook" which is a subset of the full DocBook. I've used
it myself; It's not very complicated at all, but I think it is probably rich
enough.

http://www.docbook.org/xml/simple/index.html


---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org


Re: DocBook vs Open eBook

Posted by Bernhard Huber <be...@a1.net>.
Hi
I think the reason for using Apache DTD is more historic, as at the 
beginning
the DocBook was not that much mature.
Moreover think about that the Docbook DTD is more complicate, and
it may take a bit longer to start using it.
Neither of these arguments stops from switching to the Docbook DTD.
bye bernhard



---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org


Re: DocBook vs Open eBook

Posted by Stefano Mazzocchi <st...@apache.org>.
Ivelin Ivanov wrote:
> 
> Does someone know the difference between these two standards initiatives:
> http://www.oasis-open.org/committees/docbook/
> http://www.oasis-open.org/cover/openEbook.html
> 
> They both seem to have industry backing while at the same time overlap quite
> a bit.
> 
> Also, why don't we use one of these two for our documentation instead of
> maintaining proprietary DTDs. There are tools on the market for WYWIWYG
> editing of both of these standards, which can make doc writing easier. And
> of course there are XLSTs for rendering to media from XHTML to voxml to PDF.
> 
> Regards,

> Ivelin

Ivelin,

this is a FAQ. big time FAQ, I might say. And also, it's totally
off-topic on the cocoon-dev list since forrest was created also to
manage the DTD of the xml.apache.org documentation (well, attempt to).

Anyway, in one word: both docbook/openebook are more complex that what
we need. We need to adapt the stylesheets anyway and the editing tools
are focusing on a XML/CSS solution (not toward a hardcoded WYSIWYG
experience) see XEE as an example.

Finally, our DTD reuses HTML tagnames were possible.

I hate this DTD debate because it becomes religious at some point, but
my point is: proceed incrementally. In two years, this community (now
handed over to forrest's) has managed the DTD in quite a successful
manner. Very few changes were required, yet the documentation is pretty
solid and complete in functionality.

Docbook simply tries to be too many things at the same time, but mostly
is a markup for books or collection of books. openebook is also a markup
for books.

The docbook stylesheets are so complex that there is a project to
maintain them. Look at how easy (compared to the docbook stylesheets) it
is to create a forrest skin. 

Would you want to impose the overhead of creating a skin for all the
docbook/openebook tags on the skin authors?

You might say: let's use only a subset (like almost everybody does), but
then you are not using Docbook, but a proprietary subset of docbook (and
maybe we ended up needing a feature that docbook doesn't have, so we are
using an 'extended subset' of docbook).

In short, I fear we'll end up not using docbook anyway.

So, in the good old software darwinism patter: let's the DTD evolve with
us. We already need the ability to include authoring metadata and we
might use the dublin-core namespace for this. Docbook doesn't allow this
(yet).

Bah, I see almost no value in going standard with markup when we don't
need to 'interoperate' with anybody and there is almost nothing we can
reuse from the environments where more standard markup is used.

-- 
Stefano Mazzocchi      One must still have chaos in oneself to be
                          able to give birth to a dancing star.
<st...@apache.org>                             Friedrich Nietzsche
--------------------------------------------------------------------