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: docbook tools vrs general tools [was: Proposal: LinkinginDocBook]


Paul Grosso's message dated: Mon, 24 Jun 2002 17:11:10 CDT
> 
> I see DocBook as another DTD (or XML vocabulary).  An XML Editor
> and/or composition system should be able to handle DocBook like
> "just another DTD."  There should be no reason for a special
> DocBook tool.
> 

A bit of an overstatement, I think?

While that is true in a reductionist sense, an XML editor, for
example, is ultimately a _convenience_ tool (reductio ad absurdum --
XML is just another text file format.  A text editor should be able to
handle XML like "just another file."  There should be no reason for a
special XML tool).  And an XML editor whose primary use is the
creation of database-like structures may well be far less convenient
for creating and editing DocBook documents than one whose primary use
is for text-with-markup DTDs like DocBook or TEI.  Both can "handle"
DocBook, but which would you rather _use_?

To me, the strength of the SGML/XML foundation of DocBook is indeed
that one can leverage the general tools like psgmls, jade, saxon, or
fop effectively on DocBook files.  But that does not necessarily imply
that "there should be no reason for a special DocBook tool" at various
points in the tool chain.  The art is in deciding _where_ there is
enough advantage in specialization to be worth the costs of
nongenerality and development effort.






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


Powered by eList eXpress LLC