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
without xsl and thus believe that DocBook should resist it in favor
of the customization layer!!
Conrefs
======
Regarding conrefs - the benefit I see is that it allows you to reuse
chunks/topics of content but still give you flexibility to change
certain text within.. For e.g. if an installation procedure is the
same for 2 routers, then you could use conref to change the router
name in that topic.. This is like a TE (text entitiy) feature that
was present in the DTDs and thus I'm in favor of supporting it.
Ideally, the support of conref should really be a xml spec rather
than a docbook or dita spec..
On the flip side, conrefs do introduce an extra processing step in
publishing - which is not desirable/feasible in dynamic publishing
systems where you want to dynamically organize a bunch of topics and
generate a book/topic collection out of it without having to set
conref files..
Regards.
--
Rajal
On May 9, 2008, at 12:39 PM, Johnson, Eric wrote:
+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:[EMAIL PROTECTED]
Sent: Friday, May 09, 2008 3:11 PM
To: 'Dick Hamilton'; 'Dave Pawson'; [email protected]
Cc: [EMAIL PROTECTED]
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
-----Original Message-----
From: Dick Hamilton [mailto:[EMAIL PROTECTED]
Sent: Thursday, May 01, 2008 10:53 AM
To: 'Dave Pawson'; [email protected]
Cc: [EMAIL PROTECTED]
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
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:[EMAIL PROTECTED]
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
DITA is the best answer for any XML-based document-centric
application
I've seen.
http://drmacros-xml-rants.blogspot.com/2008/04/choosing-xml-schema-
docbo
ok-or-dita.html
His last para is interesting.
why doesn't DocBook simply adopt DITA's specialization mechanism? It
would cost DocBook almost nothing to add and add tremendous value. It
would not require DocBook changing anything about its current markup
design, except to possibly back-form some base types that are
currently
not explicit in DocBook but would be useful as a specialization base.
But that would only make DocBook cleaner.
I'm not a DITA user. It appears Eliot hasn't looked at db5 either.
regards
--
Dave Pawson
XSLT XSL-FO FAQ.
http://www.dpawson.co.uk
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
open.org
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
open.org
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
