headers
Dick Hamilton | 1 May 2008 19:52
Favicon
Gravatar

RE: db 5 and Dita anyone?

Dave,

You make a good point; I suspect Eliot is not familiar with Norm's
article, "DITA for DocBook" (http://norman.walsh.name/2005/10/21/dita),
which shows how to specialize DocBook, and provides a customization
to the stylesheets to support specialization.  I posted a reply to
his blog entry suggesting he take a look at it and comment.

The question this does raise is whether it makes sense to include a
means of specialization as part of the standard.  While I like the
idea of being able to specialize, I'm sure that making it a normative
part of the spec is not trivial, even if we simply formalize Norm's
strategy.

I'd be interested in hearing what others on the list think about
formalizing specialization.  To that end, I'm copying this to the
docbook list, which is probably the best place for that discussion.

Dick Hamilton
http://rlhamilton.net

> -----Original Message-----
> From: Dave Pawson [mailto:davep <at> dpawson.co.uk] 
> Sent: Saturday, April 19, 2008 2:25 AM
> To: Docbook Apps
> Subject: [docbook-apps] db 5 and Dita anyone?
> 
> 
> Eliot is running comments on DITA and docbook when choosing an XML
> vocabulary, concluding
(Continue reading)

Permalink | Reply | 0 comments |
headers
Jean Jordaan | 8 May 2008 12:17
Picon

Couple of website comments

Hi there

A couple of things just struck me:
http://docbook.sourceforge.net/ references docbook-dsssl as one of the
"latest DocBook Project releases".
As far as I know, work on the DSSSL stylesheets has been discontinued long ago.

Also, http://docbook.org/whatis says:
"The DocBook Technical Committee of OASIS [...] plans to develop an
XML Schema for DocBook."
As far as I know, this schema has been developed.

I noticed these while scanning for good URLs to send prospective
clients, so out of data info looks bad ..

--

-- 
jean                          . .. .... //\\\oo///\\
Permalink | Reply | 0 comments |
headers
Fabrice (GMail | 9 May 2008 21:11
Picon

RE: [docbook-apps] db 5 and Dita anyone?

IMHO, specialization would be an interesting feature to add, though targeted
at advanced users. Since Docbook is explicitly designed for books, a large
number of Docbook users should be able to achieve their goals with the
current DTD/schema. My guess is that 10% to 20% of Docbook users would
really benefit from it. More feedback on this from the community would help.

I see more value in adding "DITA-like conref" support. Content re-use is one
of the key benefits you get when moving to single-source. Adding a simple
way for authors to re-use small piece of content in Docbook would make a big
difference!

Cheers
Fabrice

-----Original Message-----
From: Dick Hamilton [mailto:rlhamilton <at> frii.com] 
Sent: Thursday, May 01, 2008 10:53 AM
To: 'Dave Pawson'; docbook <at> lists.oasis-open.org
Cc: docbook-apps <at> lists.oasis-open.org
Subject: RE: [docbook-apps] db 5 and Dita anyone?

Dave,

You make a good point; I suspect Eliot is not familiar with Norm's
article, "DITA for DocBook" (http://norman.walsh.name/2005/10/21/dita),
which shows how to specialize DocBook, and provides a customization
to the stylesheets to support specialization.  I posted a reply to
his blog entry suggesting he take a look at it and comment.

The question this does raise is whether it makes sense to include a
(Continue reading)

Permalink | Reply | 0 comments |
headers
Johnson, Eric | 9 May 2008 21:39
Favicon

RE: RE: [docbook-apps] db 5 and Dita anyone?


+1 to DITA-like conref support.

It would be nice to have a way to easily reuse pieces of content without
having to import their containing element. There are many times I have
had a chapter in a small book that I would like to have used as a
section in a large book without importing the chapter section by section
using xinclude.

-----Original Message-----
From: Fabrice (GMail) [mailto:fabrice.talbot <at> gmail.com] 
Sent: Friday, May 09, 2008 3:11 PM
To: 'Dick Hamilton'; 'Dave Pawson'; docbook <at> lists.oasis-open.org
Cc: docbook-apps <at> lists.oasis-open.org
Subject: [docbook] RE: [docbook-apps] db 5 and Dita anyone?

IMHO, specialization would be an interesting feature to add, though
targeted at advanced users. Since Docbook is explicitly designed for
books, a large number of Docbook users should be able to achieve their
goals with the current DTD/schema. My guess is that 10% to 20% of
Docbook users would really benefit from it. More feedback on this from
the community would help.

I see more value in adding "DITA-like conref" support. Content re-use is
one of the key benefits you get when moving to single-source. Adding a
simple way for authors to re-use small piece of content in Docbook would
make a big difference!

Cheers
Fabrice
(Continue reading)

Permalink | Reply | 0 comments |
headers
Barton Wright | 9 May 2008 22:08
Favicon

RE: RE: [docbook] RE: [docbook-apps] db 5 and Dita anyone?

Another +1 for a non-xinclude conref feature. 

No one talks about the hidden cost of xincludes, which is that they are expensive in terms of the time they
take in a large Java-based doc build process. The more xincludes our doc set accrues, the longer the doc
build takes. 

-----Original Message-----
From: Johnson, Eric [mailto:Eric.Johnson <at> iona.com] 
Sent: Friday, May 09, 2008 3:40 PM
To: docbook <at> lists.oasis-open.org
Cc: docbook-apps <at> lists.oasis-open.org
Subject: [docbook-apps] RE: [docbook] RE: [docbook-apps] db 5 and Dita anyone?

 
+1 to DITA-like conref support.

It would be nice to have a way to easily reuse pieces of content without
having to import their containing element. There are many times I have
had a chapter in a small book that I would like to have used as a
section in a large book without importing the chapter section by section
using xinclude.

-----Original Message-----
From: Fabrice (GMail) [mailto:fabrice.talbot <at> gmail.com] 
Sent: Friday, May 09, 2008 3:11 PM
To: 'Dick Hamilton'; 'Dave Pawson'; docbook <at> lists.oasis-open.org
Cc: docbook-apps <at> lists.oasis-open.org
Subject: [docbook] RE: [docbook-apps] db 5 and Dita anyone?

IMHO, specialization would be an interesting feature to add, though
(Continue reading)

Permalink | Reply | 0 comments |
headers
Rajal Shah | 9 May 2008 22:23

Re: RE: [docbook-apps] db 5 and Dita anyone?

Hello -

Specialization
==========
The value of specialization, really is  a way to develop more  
semantic compact xml structure based on your doc needs.. The way DITA  
does specialization is by putting all elements in the base DTD and  
the specialization is allowing you to choose a subset of those  
elements in your DTD .. (They do allow renaming of elements which  
makes it appear that you can extend the base DTD set, but it really  
isn't..)

The specialization feature is an impressive new concept in that your  
stylesheets are not based on the element names but off the base  
classes (much like in object oriented coding).. The stylesheet coding  
to support this is very messy from my perspective to maintain though.  
I believe that the docbook customization layer in stylesheets is a  
better approach.. NOTE: There are 2 competing thoughts in the DITA  
world on whether specialization is a good thing or not.. Some of them  
strongly advocate that specialization should be discouraged and is  
not DITA if you do that..

The one business need that DITA is trying to solve with  
specialization - based on all my discussions with the DITA experts -  
is that it allows you to share/distribute your xml content files  
without having to distribute the stylesheets.. The base stylesheets  
would be installed on every computer and because your specialzed  
document is a subset of the base DITA dtd, you are guaranteed at  
least a default rendering of the document.. I personally, don't  
believe that most people have that business need to distribute xml
(Continue reading)

Permalink | Reply | 0 comments |
headers
Peter Desjardins | 9 May 2008 22:35
Picon

Re: RE: [docbook] RE: [docbook-apps] db 5 and Dita anyone?

On Fri, May 9, 2008 at 4:08 PM, Barton Wright
<barton.wright <at> streambase.com> wrote:
> Another +1 for a non-xinclude conref feature.
>
> No one talks about the hidden cost of xincludes, which is that they are expensive in terms of the time they
take in a large Java-based doc build process. The more xincludes our doc set accrues, the longer the doc
build takes.

This is the biggest problem I have encountered with DocBook.  I've
achieved whatever content reuse I've needed so far using xincludes and
xpointer.  I posted the permutations that I find useful here:

     http://wiki.docbook.org/topic/DocBookCookbook

But they only work with xmllint.

My experience with xincludes is that they resolve very quickly,
though.  Especially after I configured an XML catalog for xmllint, it
resolves my intricate web of xincludes in seconds.  Maybe the
difference is that you are using a Java tool to resolve them?

I would gladly give up the xincludes for a DocBook content sharing feature.

Peter
Permalink | Reply | 0 comments |
headers
Bob Stayton | 9 May 2008 23:38

Re: RE: [docbook] RE: [docbook-apps] db 5 and Dita anyone?

The first step for getting something like conrefs is to raise it with the 
DocBook Technical Committee.  Please file an RFE in the DocBook project on 
SourceForge.  That will get it onto the TC agenda.

Bob Stayton
Sagehill Enterprises
bobs <at> sagehill.net

----- Original Message ----- 
From: "Peter Desjardins" <peter.desjardins.us <at> gmail.com>
To: "Barton Wright" <barton.wright <at> streambase.com>
Cc: "Johnson, Eric" <Eric.Johnson <at> iona.com>; <docbook <at> lists.oasis-open.org>; 
<docbook-apps <at> lists.oasis-open.org>
Sent: Friday, May 09, 2008 1:35 PM
Subject: Re: [docbook-apps] RE: [docbook] RE: [docbook-apps] db 5 and Dita 
anyone?

> On Fri, May 9, 2008 at 4:08 PM, Barton Wright
> <barton.wright <at> streambase.com> wrote:
>> Another +1 for a non-xinclude conref feature.
>>
>> No one talks about the hidden cost of xincludes, which is that they are 
>> expensive in terms of the time they take in a large Java-based doc build 
>> process. The more xincludes our doc set accrues, the longer the doc build 
>> takes.
>
> This is the biggest problem I have encountered with DocBook.  I've
> achieved whatever content reuse I've needed so far using xincludes and
> xpointer.  I posted the permutations that I find useful here:
>
(Continue reading)

Permalink | Reply | 0 comments |
headers
Dave Pawson | 10 May 2008 09:05
Picon

Re: RE: [docbook-apps] db 5 and Dita anyone?

Rajal Shah wrote:

> The one business need that DITA is trying to solve with specialization - 
> based on all my discussions with the DITA experts - is that it allows 
> you to share/distribute your xml content files without having to 
> distribute the stylesheets.

Docbook does that already? Why can't I share a chapter/section/sectN?

I've not heard a use case for 'specialization' yet on this thread
(Other than 'they do it' it must be good).

The Xinclude overhead is likely a low use case soluable by
more processing power when needed. Or use entities.

regards

--

-- 
Dave Pawson
XSLT XSL-FO FAQ.
http://www.dpawson.co.uk
Permalink | Reply | 0 comments |
headers
Dave Pawson | 10 May 2008 09:08
Picon

Re: [docbook-apps] RE: [docbook] RE: [docbook-apps] db 5 and Dita anyone?

Peter Desjardins wrote:
> On Fri, May 9, 2008 at 4:08 PM, Barton Wright
> <barton.wright <at> streambase.com> wrote:
>> Another +1 for a non-xinclude conref feature.
>>
>> No one talks about the hidden cost of xincludes, which is that they are expensive in terms of the time they
take in a large Java-based doc build process. The more xincludes our doc set accrues, the longer the doc
build takes.
> 
> This is the biggest problem I have encountered with DocBook.  I've
> achieved whatever content reuse I've needed so far using xincludes and
> xpointer.  I posted the permutations that I find useful here:
> 
>      http://wiki.docbook.org/topic/DocBookCookbook
> 
> But they only work with xmllint.

Agreed on xpointer, not really surprising though. Xinclude works
fine with Saxon and xerces.

regards

--

-- 
Dave Pawson
XSLT XSL-FO FAQ.
http://www.dpawson.co.uk
Permalink | Reply | 0 comments |

Gmane